In D58314#1339359, @feld wrote:

In D58314#1339356, @kib wrote:

This obviously changes the semantic of the pwait(1) tool. Before, it returned control after the process exited. Now, it additionally wait until a reaper makes the wait*() call.

But what does "exited" really mean in this context?

This obviously changes the semantic of the pwait(1) tool. Before, it returned control after the process exited. Now, it additionally wait until a reaper makes the wait*() call.

In D58264#1339299, @markj wrote:

In D58264#1339297, @kib wrote:

proc_to_reap(orphan) can reap.

I promised to look at the tests if there is an agreement on the idea of this change. I know that there is some breakage.

Some summary of 1) current semantics 2) proposed semantics would be useful. The review description is not very clear.

As I understand it, 2) is:

• only the parent can reap the child, by calling wait() or pdwait(),
• any procdescs which refer to the child will prevent the child PID from being recycled,
• anybody may use pdwait() to fetch the status of the child, but only the parent can consume the status.

proc_to_reap(orphan) can reap.

In D58264#1339293, @markj wrote:

Did you run the ptrace tests? Several fail, and then I see a panic

panic: reaped an orphan (pid 0)
cpuid = 13
time = 1784674501
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0xa5/frame 0xfffffe00f1a525b0
kdb_backtrace() at kdb_backtrace+0xc6/frame 0xfffffe00f1a52710
vpanic() at vpanic+0x214/frame 0xfffffe00f1a528b0
panic() at panic+0xb5/frame 0xfffffe00f1a52980
kern_wait6() at kern_wait6+0x57c/frame 0xfffffe00f1a52a10
sys_wait4() at sys_wait4+0x18e/frame 0xfffffe00f1a52d10
amd64_syscall() at amd64_syscall+0x3d8/frame 0xfffffe00f1a52f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00f1a52f30
--- syscall (7, FreeBSD ELF64, wait4), rip = 0x3ce8fd7e46ea, rsp = 0x3ce8f93b2d78, rbp = 0x3ce8f93b2db0 ---

Rename PZOMBIEREF_ORPHAN to PZOMBIEREF_REALPARENT.
Move an assert into proc_realparent().
Correct the condition to reparent on the last procdesc close.
Start modifying the man pages.

Fix one more locking comment.

Change p_zombieref lock annotation to be just proctree_lock.

Will be consumed by D58264

Add a control variable for proc_can_ptrace() calls.

Remove the weird block.
Several minor fixes accumulated from the testing.

Allocate children big enough to hold information about all children processes, regardless of the p_cansee() return value.

This is still not intended for review, I just demonstrate the (IMO) full branch where the end is the ability to run truss in cap mode.
I am posting individual commits from the branch for review still.

Update comment.

Edit comments and the man page update.

Use atomic to load p_flag.

Fix PTCHLD_TRACED_BY_ME.
Check uap->data < 0.
Use more correct type for rsrv[] to avoid compat32 conversions.
Man page editing.

In D58315#1338064, @markj wrote:

Why not implement this with procctl()? That seems more natural to me.

please re-upload the patch with the full context.

Add PTCHLD_TRACED_BY_ME.
Add space for future ABI expansion.

Please upload patches with the full context.

In D58321#1337618, @netchild wrote:

So you disagree with kern.features.exterror.
Do you also disagree with kern.features.exterr_strings which covers the optional behavior of verbose exterror and is useful in unit tests to differentiate between "fails because something is wrong -> error" and "fails because it does not exist -> intendet -> ok".

In D58191#1337590, @pho wrote:

I ran all of the stress2 tests without seeing any issues.

This adds two syscalls to each dynamic syscall failure path. I understand that calling the sysctl is the easiest way to handle dynamically loaded modules. But I already got some negative comments due to exterrors adding some nanoseconds to the failing syscalls timings.
Although I do not object in principle, can we have some smarter way to avoid the sysctl if we already queried the specific module? E.g. we can make each module to register 'range' for dynamic errors' pathes, and memoize the range with the values in libc.
This is esp. sorrow because the display of the source line is really a niche feature.

Could somebody provide an isolated test for the situation where the patch is needed?

As I said it elsewhere, there is no point in kern.features.exterror. You cannot run 15 userspace on <= 14 kernel.