I think so, yeah. Please make sure to test it though; iirc previously the “nocover” option support wasn’t MFC-ed and I had to work around it.

I have no idea if this is still required, but if it is: please go ahead.

It's the first time I see errx(0, ...);, and I find it somewhat confusing, compared to warnx(...); return (0);, but grepping the source it's used like that in other places, so I guess it's just me :-)

I wonder why it's there in the first place. Does autoloading dependencies (linuxkpi) on kldload iser work without it?

There is a somewhat related issue in https://reviews.freebsd.org/D26240. Do you think you could fix it as well, by throwing in an mkdir(1) somewhere in linux_mount?

Sigh, sorry, it's my fault; every few months I got reminded about this, then find a problem, try to fix it, and then I get distracted and the cycle repeats.

Fix build on arm64.

In D32756#740162, @kib wrote:

What about i386 and linux32 on amd64?

Fix ifdefs.

Tinderboxed.

Tweak the comment.

Fix issues pointed out by kib@.

Sigh, no, you were right. My comment is for https://reviews.freebsd.org/D32601, not for this one here.

In D32616#738055, @emaste wrote:

Was this just an incorrect understanding in R10:faf2fa21d70b1e625cb7af032e6608e631931486?

Thanks! See https://reviews.freebsd.org/D32726.

Okay, so as usual Konstantin is right: the patch is wrong, in that it adds an extra stop even if the ptracing process is native, not Linux. This needs to be fixed.

In D32367#736014, @kib wrote:

BTW, why cannot this be done somewhere in linux_on_exec(), or similar place?

In D32355#736013, @kib wrote:

In D32355#735891, @trasz wrote:

In D32355#734342, @kib wrote:

In D32355#734044, @trasz wrote:

Is there any practical scenario where this can be a problem?

Definitely, this is how EINTR is returned from syscall after a signal handler was run.

I'm not sure if Linux' ptrace API defines it this way. Also, I don't quite understand how it works for FreeBSD binaries, given that kern_ptrace() only fills sr_retval if sr_error == 0. Therefore I'm tempted to commit it as is, particularly given that it fixes a trivially-reproducible panic.

For native FreeBSD we can legitimately expose EJUSTRETURN. This is enough to inform caller that the real state is in the registers file.

For Linux, due to different ABI and absense of EJUSTRETURN, I have no other proposal than to decode the state (to have the code correct).

Let the ptracer fallback to another method.

In D32355#734342, @kib wrote:

In D32355#734044, @trasz wrote:

Is there any practical scenario where this can be a problem?

Definitely, this is how EINTR is returned from syscall after a signal handler was run.

Might be worth making the same change to usr/sbin/fstyp/msdosfs.c; it's largely copy/pasted from here.

In D32355#734021, @kib wrote:

In D32355#734020, @trasz wrote:

Isn't EJUSTRETURN always a success?

EJUSTRETURN means 'take the saved frame content and load it into CPU registers without any changes'. Now compare this with usual syscall return, which puts return values into some registers, set or clear error indicator etc.