Assert that P_WEXIT is set in procdesc_exit(), It is trivially true because procdesc_exit() is only called from exit1() after single-threading.
Assert that pd->pd_fcount > 0 when pd already found in kern_pdopenpid().
Fix the arg number in bsm.
Write some documentation for the interface. Try to explain the quirk of multiple pdopenpid()s,

Handle review notes except pd_fpcount == 0/PDF_DAEMON case.

I think it could be set to 'enabled' for machines with DMAP, i.e. amd64/arm64, and might be risc-v, if anybody ever uses nfs server on it. For other arches, the knob almost surely should be kept disabled.
mb_unmapped_to_ext() uses non-privately mapped sfbufs for all extents of mbufs. On DMAP systems, it is free. On other arches, allocating such sfbuf causes global IPI, and the whole chain of sfbufs is freed only after the mbufs are released by the network card. Besides the cost of allocating , this would make sfbufs scarce resource for other consumers and even for nfs server itself. There are around ~1K of sfbufs, and it mb_unmapped_to_ext() seems to drop packet if an sfbuf cannot be allocated immediately.

In D57149#1309608, @markj wrote:

In D57149#1309603, @kib wrote:

I would also consider adding some timeout by counting the number of usleep() calls, to avoid infinite wait.

kyua itself provides a timeout mechanism, I think it's ok to rely on that?

I would also consider adding some timeout by counting the number of usleep() calls, to avoid infinite wait.

exterr_cat_filenames.h should be regenerated.

Track number of open files for given procdesc. Drop PDF_CLOSED flag.

In D57038#1309123, @monwarez_mailoo.org wrote:

Thanks for the work, could it be possible to have the ntsync.h headers available in a path that can be resolved by:

<linux/ntsync.h>

This would make it easier to use it with wine since then no specific code for FreeBSD would be necessary which I would assume is the main objective to this kernel module.

Allow to have more than one file referencing procdesc.
I am unable to find a broken situation, so lift the restriction.

Fix memory leak in cleanup for EINVAL when waiting for the same object twice in WAIT_ALL.

Provide dedicated error values for cases when the target process is exiting, or when the procdesc is already allocated for it.

Illustrative program

/* $Id: pdopenpid.c,v 1.1 2026/05/20 05:16:25 kostik Exp kostik $ */

Minor wording

Fix !DEBUG build.
Fix headers installation.

In D57038#1308673, @kenrap_kennethraplee.com wrote:

From build testing with the latest changes, I've ran into 3 build errors and have suggested fixes for each:

Make tests in linuxolator pass fully.

linux compat mostly works.
Match native FreeBSD ioctl args with Linux counterparts.

Add linux compat code. Cannot test with linux test, since it uses pidfd calls which are not implemented.

Could you please also document the '_' quirk?

Return status from vn_lock_pair().

I do not believe that strip could remove section headers. It is either linker script or linker which would do that, or some more involved ELF editing tool.
Point is that rtld does not need sections at all.

I would also mention that the function uses section headers to look up symtab, which means that a legitimate binary with sections stripped would not work.

Make vfs_mount() handle a possibility that covered vp and new mount fs rootvp share the locks.

Report some info on stat(2)

Report kinfo for ntsync filedescs.
Minor tweaks overall.

In D57054#1307333, @jrm wrote:

In D57054#1307326, @kib wrote:

I looked at the referenced bug. Could you please conduct an experiment where the failing machine is booting kernel with just the WRMSR write to actually update the ucode is commented out? I mean, remove only the instruction, but keep the setup for wrmsr_safe intact. Does the machine boot in this case?

I'll try to answer both questions here.

My understanding of this is not much beyond this: Commit d9f03a43f2fe seemed the most likely change to have caused a problem, especially since @glebius said Intel wasn't tested.

But after the dlopen(RTLD_DEFER_INIT), would the object participate in the symbol resolution? If yes, it is unsafe. If no, it is probably too hard to implement for the effect.

Please change the title from 'Overhaul remount handling' to 'Overhaul remount options handling'.
Quite non-trivial part of the remount handling for tmpfs is rw->ro remount, and from the title I thought that you rewrote that.

I looked at the referenced bug. Could you please conduct an experiment where the failing machine is booting kernel with just the WRMSR write to actually update the ucode is commented out? I mean, remove only the instruction, but keep the setup for wrmsr_safe intact. Does the machine boot in this case?

In D57054#1307284, @imp wrote:

What are the risks this a avoids?

Handle NULL parameters.

In D57036#1306961, @mckusick wrote:

Why does ufs_bmap_seekdata() cause a panic when it uses an unmapped buffer?

For purposes of ssh, is it ever right to look into the non-dynamic symbols? And if not, should it use dlsym() instead?

Reword the sentence.

In D56989#1306035, @jhb wrote:

In D56989#1305907, @kib wrote:

For me, the segment registers values from the trap frame appeared to be very useful and sometimes even instrumental, e.g. during the recent FRED work. If the kernel idea of the trap frame address is misaligned with the location where the hardware put it, segment values are canaries that allow to see that immediately. Also, bugs with segments handling in doreti or fred_gouser are relatively obvious then. I am asking to keep that in the frame dump.

Ok. Do you care about there code segment details from the GDT?

x86/iommu part is certainly fine.

For me, the segment registers values from the trap frame appeared to be very useful and sometimes even instrumental, e.g. during the recent FRED work. If the kernel idea of the trap frame address is misaligned with the location where the hardware put it, segment values are canaries that allow to see that immediately. Also, bugs with segments handling in doreti or fred_gouser are relatively obvious then. I am asking to keep that in the frame dump.

On amd64 it is certainly enough to check PHYS_IN_DMAP(start+size), since DMAP always goes from 0 to TOP. Not sure about other arches.