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 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()

In D47350#1084720, @kevans wrote:

In D47350#1084710, @kib wrote:

Why abandon? This is useful in general.

I wasn't sure if it was worth doing if I don't have a consumer in mind now that I have lsan off of it- I'm more than happy to go ahead and push it if you think it's still useful.

Why abandon? This is useful in general.

In D47556#1084670, @emaste wrote:

If you move the page to section 3, it should be in lib/libc/gen.

I wondered about that, but the implementation is in libsys and there are a small number of section 3 pages in libsys, like getpagesize.3, so should be the same for sched_getcpu, no?

If you move the page to section 3, it should be in lib/libc/gen.

Now after a fresh look, I suggest to change the new function to be read-only. What I mean, is to remove hold/unhold_object and marker linkage. I believe this is 'better' in the sense that it would induce the UB memory accesses on the caller, but other threads would not see unlocked updates.

In D47523#1084448, @markj wrote:

In D47523#1084446, @kib wrote:

Well, I initally mean to simply convert B_ASYNC to sync by clearing the flag, if runningbufspace limit would be hit. My reasoning to switch to TDP_NORBS is to be more like existing solution for the buffer daemon instead, to not provide two separate hacks for the same problem. I do not think that B_ASYNCWAIT is needed.

This is what I tried first, it doesn't work. bufdone() needs to know about this special case, since it handles completion differently depending on whether B_ASYNC was set or not.

In D47523#1084327, @markj wrote:

I think this change is probably ok.

The larger invariant to preserve is that the filesystem cannot issue async I/O to implement bstrategy(). If it does, then the maximum number of recursive I/Os must be less than lorunningspace/maxphys (on small memory systems this can be 0), OR, the code issuing the async writes must set TDP_NORUNNINGSPACE.

I tried implementing your suggestion to make bufwait(B_ASYNC) block if the write exceeds the hirunningspace threshold. I think this solves the problem, but it's hard to be sure, as the bawrite() in softdep_process_journal() is hard to trigger (normally this work is handled by the flushing thread). It is a bit complex (requires a new B_ASYNCWAIT buf flag and some locking to synchronize the sleep/wakeup), but I believe it relaxes this invariant. I'm not sure whether to continue working on it.

Ping?