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?

Drop P_SWAP* descriptions.

It is not only the vendor code, but the whole spec for Processor ACPI vendor-specific fixed functions. It is only Intel which specified something, which is why I only enabled it on Intel.

amd64/amd64/fpu.c seems to be the natural place for the new functions.
Despite named 'fpu', the file deals with the whole non-GPR part of the CPU state.

It should be fine modulo the note about vhold() no longer needed.

There are two additional useful things to do there:

• stop using devp.handle for handle, it seems to always copy the actual handle. Then, the entry can be renamed back to dev and guaranteed to be either NULL or cdev, and it can be cdev in more cases.
• add cdev pager method to return user-visible name, to fill into procstat and vmstat -o.

Yes this is almost exactly what I mean by dl_iterate_phdr_locked().

How do you handle DMA operations possibly still occuring at the panic or reboot time? For panic, the paniced kernel definitely does not do anything to stop them. For reboot, I am aware that e.g. mlx5 driver does nothing to stop PCIe interface from executing commands and writing updates to several rings, also the UMA memory is kept owned by the card until reset is done. Similarly, GPUs which have host memory allocated for them, might do DMA ops for long time after the host started smelling funny.

We can export something like dl_iterate_phdr_locked() in private namespace, which would not take the phdr lock, if the problem is with it.