You just merge it when you think that there is enough testing done in head, as usual. Or, is there some more background context I am not aware of?

In D35084#797142, @andrew wrote:

I have a patch to use an IPI in pmap_update_entry. The variable to exit the loop is from the caller stack so would break exceptions in the same way if we promote/demote the page.

The main issue is deciding on which memory will need to use an IPI. I prototyped using a software flag in the pte, however this is likely to stop promotion as pmap_promote_l2 checks these attributes are identical over the entire range before promotion.

I checked for the described condition by testing for rv == 1. Then it does not need this long comment.

Space in .Dv NULL ,
Bump man page date in advance.

ping?

Does it make sense to add asserts in the demotion code to ensure that it does not touch pcpu mappings? Or even, somewhat more to the point, in the break-before-make code.

In D35014#795107, @markj wrote:

Since PROC_REAP_KILL only operates with P_PID, it could set the PCTL_UNLOCKED flag instead, and the stop_all_proc and proctree locks can be acquired in the proper order within reap_kill().

Avoid LOR between stop_all_proc_block() and proctree_lock.

In D35068#794804, @dchagin wrote:

In D35068#794803, @kib wrote:

I do not quite understand this. Am I right that the intent is to see zombies under linprocfs? If yes, what exact entries from the pid directory should be exposed?

yes, you are right.
linprocfs_doprocstatus, PFS_ZOMBIE flag of pfs_create_xxx()

I do not quite understand this. Am I right that the intent is to see zombies under linprocfs? If yes, what exact entries from the pid directory should be exposed?

Use sx for stop_all_proc_block().
Upgrade proctree_lock assert to XLOCKED in reaper_abandon_children().

In D35014#794658, @markj wrote:

Seems ok to me. One general comment: we have to stop the target process because we have no mechanism to synchronize with a forking process. For example, a per-proc sx lock which is held for the duration of fork, so other threads can block until the target is finished forking. Or some blockcount-like barrier. I think I added such a thing for Isilon a long time ago to fix a problem with dtrace, IMO it would be useful here too. Do you agree?

Fix condition for need_stop: it should check that REAPER_KILL_CHILDREN is not set. REAPER_KILL_SUBTREE is legitimately unset when all descendants of the reaper must be killed.

Handle Mark' comments.

Fix error/errno meh.

In D34850#790822, @jhb wrote:

Note that FreeBSD would benefit from similar changes in the native API btw. As it was we can't safely raise MAXCPU in the default amd64 kernel (for example) because it breaks the ABI since old kernels would be too pick about userland having a larger size. It would be good perhaps to fix the native syscalls to adopt Linux's more flexible semantics and then you would not need to change the Linux ABI itself.

Add stop_all_proc_blocker.

Stop the victim while signalling.

Per-commit view is available at https://kib.kiev.ua/git/gitweb.cgi?p=deviant3.git;a=shortlog;h=refs/heads/reap

If this is a laptop (judging by ahci/amount of memory), you most likely have two DMARs, one serving the GPU, and another covering all PCIe devices. In this configuration, whatever was protected by PMR for GPU, does not make sense to unprotect.

In D34907#792865, @mindal_semihalf.com wrote:

In D34907#792838, @kib wrote:

As a second though, this control is global. Do you want it to be per-DMAR unit, in fact? [I am fine with this refine to be done later]

IMHO having one knob is better:

1. Other DMAR related tunables are "global", e.g. hw.dmar.enable, hw.dmar.dma.
2. From user perspective if they want to disable PMR it's probably on all units.

Otherwise we'd end up in a weird situation where some devices can access memory that was previously used by firmware and other don't.
I can't think of a scenario where that would be useful.

As a second though, this control is global. Do you want it to be per-DMAR unit, in fact? [I am fine with this refine to be done later]

Doesnt' all real-time priority threads run to completion? In other words, if all ithreads are put under the same priority, then there is no preemption to let other ithread to run until current ithread finishes? To put it differently, making ithreads time-share interrupt time requires changes to the schedulers, not just adjusting the priorities.

BTW, should PAGE_SIZE be the least guaranteed page size? In other words, should some test ensure _Static_assert(PAGE_SIZE <= ps[0]). Also perhaps something about ps[0] being multiple of PAGE_SIZE worth to be guaranteed?

Regardless of the notes I put above, please mail me the git patch with the correct 'Author' metadata.

I am not sure that I like/agree with the patch. My main objection is that you are unconditionally tickle PMR despite DMAR state. In fact, it is quite far from the place where you put the call to dmar_disable_protected_regions(), to the actual enable of translation.