In D47768#1089266, @jah wrote:

Oops, I didn't see this until after I wrote and tested my own version: https://reviews.freebsd.org/D47769

In D47741#1088847, @kevans wrote:

In D47741#1088837, @kib wrote:

In D47741#1088794, @kevans wrote:

In D47741#1088787, @kib wrote:

Is the problem caused by the fact that AST_SIG is processed before AST_SIGSUSPEND? Would reordering the AST indexes be enough?

As I understand, the complain is that signal ast handler might push the signal frame before sigsuspend handler restores the sigmask which marks the signal as blocked?

AST_SIG has to be processed before AST_SIGSUSPEND in order for the temporary signal mask stuff to work, AFAICT,

Do you mean AST_SIGSUSPEND scheduling from kern_sigsuspend()? If yes, then perhaps we need AST_SIGSUSPEND2, which is scheduled from pselect/ppoll and processed after AST_SIG.

I mean AST_SIGSUSPEND as scheduled from here- if seltdwait()'s sleep was interrupted by a signal, then my understanding is that we need to keep the temporary signal mask installed all the way until AST_SIG is done in order to process signals that are blocked by the old signal mask, but not by the temporary signal mask.

In D47741#1088794, @kevans wrote:

In D47741#1088787, @kib wrote:

Is the problem caused by the fact that AST_SIG is processed before AST_SIGSUSPEND? Would reordering the AST indexes be enough?

As I understand, the complain is that signal ast handler might push the signal frame before sigsuspend handler restores the sigmask which marks the signal as blocked?

AST_SIG has to be processed before AST_SIGSUSPEND in order for the temporary signal mask stuff to work, AFAICT,

Is the problem caused by the fact that AST_SIG is processed before AST_SIGSUSPEND? Would reordering the AST indexes be enough?

In D47739#1088711, @markj wrote:

In D47739#1088673, @kib wrote:

Just realized that this is a kernel memory exposure.

Yes :(

It looks like the problem can happen "only" when a nullfs file mount is present?

Just realized that this is a kernel memory exposure.

Mark rt call region with TDP_EFIRT. It allows to not depend on the implementation detail of disabling page faults in the region.

Reformulating what @imp said, loader is executing in EFI boot services environment, while EFI RT is EFI runtime services client. The switch of the environment is supposed to pass ownership of the machine to OS, and also the rt code must be relocated. The later is known to be often buggy. This is why I implemented onfault handling for RT calls.

Reorder checks. Explain why I did not wanted to do it initially.

Add some debugging

So currently ETXTBSY does not work?

In D47588#1085785, @kib wrote:

My feeling is that it is strange to claim that fork is 2024. It costs nothing to say there specifically that it is -p1003.1 (might be even -88, but I do not have the text).

My feeling is that it is strange to claim that fork is 2024. It costs nothing to say there specifically that it is -p1003.1 (might be even -88, but I do not have the text).

Also _Fork()