Created attachment 268877 [details] procctl: add extended reaper status query This patch adds a new procctl(2) operation, PROC_REAP_STATUS_EX, to provide extended introspection of existing reaper-managed process trees. The current PROC_REAP_STATUS interface remains unchanged for compatibility. The new PROC_REAP_STATUS_EX query returns additional information about the target process, including: - owning reaper PID - subtree identifier - real parent PID - whether the process is a direct child of its reaper - whether the process is itself a reaper - for reaper processes, the number of direct children and tracked descendants The patch also updates procctl(2) to document the new operation and its associated structure and flags. Motivation: The existing reaper infrastructure already tracks subtree relationships, but userland has only limited visibility into them. This change provides a small, opt-in extension for userland tools that need more detailed process-tree introspection. Testing: - Built and booted a kernel containing the change on FreeBSD-CURRENT. - Verified that ordinary processes report the expected init-rooted reaper state. - Verified that a process after PROC_REAP_ACQUIRE reports itself as a reaper. - Verified that direct children and grandchildren report the expected reaper and subtree values. - Included a small userland C test program as an attachment for reviewer use. This is intended as a focused introspection improvement; it does not modify the behavior of existing reaper operations.
Created attachment 268878 [details] procctl_reap_status_ex_test.c
Created attachment 268879 [details] procctl_reap_status_ex_test.log Attached is sample output from the included userland test program, showing expected behavior for: - an ordinary process - a process after PROC_REAP_ACQUIRE - a direct child of a reaper - a grandchild in the same reaper subtree - descendant counting while descendants are alive
After discussing the design off-list, I decided to rework the approach and move away from introducing a new procctl interface returning derived reaper topology data. The main issue with the previous design is that it returned state that is only consistent while the process tree lock is held, meaning the information can become stale immediately after returning to userland. Given that, it makes more sense to either reconstruct the data in userland or export only the minimal raw information required to do so. Following this direction, I am now extending struct kinfo_proc to export the missing raw reaper metadata: - ki_reaper: pid of the owning reaper - ki_reapsubtree: subtree identifier The existing kinfo_proc fields already provide pid and real-parent information, so with these additions userland can reconstruct the reaper hierarchy from kern.proc.all / kern.proc.proc without requiring a dedicated syscall or kernel-side interpretation. I believe this approach fits better with existing interfaces because: - it avoids introducing a new syscall for data already present in the kernel, - it keeps interpretation and policy in userland, - and it integrates naturally with existing sysctl and libkvm consumers. The implementation updates: - fill_kinfo_proc() to populate the new fields under the appropriate locks, - libkvm (kvm_proclist) for crash dump consumers, - and the freebsd32 compatibility structures and copyout path. I am currently running build and runtime tests (including a userland validation program for reaper/subtree relationships). I will attach the revised patch and test results once testing is complete.
Created attachment 269908 [details] kern/proc: expose reaper PID and subtree root in kinfo_proc
Created attachment 269909 [details] kern-proc_reap_status_test.c
Created attachment 269910 [details] kern-proc_reap_status_test.log
The patch has been revised and testing is now complete. The new approach (described in comment 3) has been fully implemented and validated. Rather than introducing a new procctl operation, the patch extends struct kinfo_proc with two new fields: - ki_reaper: PID of the owning reaper process - ki_reapsubtree: PID of the direct child of the reaper that roots the subtree the process belongs to Both fields are pid_t to match their kernel-side counterparts (p_reaper->p_pid and p_reapsubtree in struct proc), and are consistent with the existing procctl_reaper_pidinfo interface. The two remaining KI_NSPARE_INT slots are consumed (KI_NSPARE_INT 2->0), with no change to sizeof(struct kinfo_proc). The following components are updated: - sys/sys/user.h: new fields added from spare slots - sys/kern/kern_proc.c: fill_kinfo_proc_pgrp() populates the new fields; p_reaper is NULL-guarded with NO_PID fallback, consistent with how ki_tpgid is handled; access is safe under proctree_lock held shared by the sysctl machinery - lib/libkvm/kvm_proc.c: kvm_proclist() updated for crash dump consumers, with matching NULL guard - sys/compat/freebsd32/freebsd32.h and freebsd32_kinfo_proc_out(): 32-bit compat struct and conversion updated Runtime validation was performed using a userland test program (attached as kern-proc_reap_status_test.c, with output in kern-proc_reap_status_test.log) covering: - Baseline state before PROC_REAP_ACQUIRE (children show init as reaper) - Post-acquire state (children correctly show the acquiring process as reaper, with per-child subtree roots) - Direct-child subtree tracking - Post-release reparenting back to init All tests pass. The revised patch is attached as kern/proc: expose reaper PID and subtree root in kinfo_proc. With these two fields exposed via kern.proc.all, userland can reconstruct reaper hierarchies without any new kernel interface. The snapshot consistency caveat noted in the earlier review applies equally here, consistent with existing fields such as ki_ppid.
Can you put the patch on the phabricator?
(In reply to Konstantin Belousov from comment #8) Opened Phabricator differential review at: https://reviews.freebsd.org/D56538
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=0f89380a3d208d67698f2d35afd35257e5fdbe09 commit 0f89380a3d208d67698f2d35afd35257e5fdbe09 Author: GenericRikka <rikka.goering@outlook.de> AuthorDate: 2026-04-20 23:32:49 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2026-04-21 23:36:07 +0000 kern/proc: expose reaper PID and subtree root in struct kinfo_proc Expose process reaper metadata through struct kinfo_proc so userland can reconstruct reaper hierarchies from kern.proc.all without adding a new procctl(2) operation. Two pid_t fields are added by carving 8 bytes from ki_sparestrings (46 -> 38), restoring KI_NSPARE_INT to 2 and keeping sizeof(struct kinfo_proc) unchanged: ki_reaper: PID of the owning reaper process ki_reapsubtree: PID of the direct child of the reaper that roots the subtree the process belongs to fill_kinfo_proc_pgrp() populates both fields under proctree_lock. kvm_proclist() is updated for crash dump consumers. The freebsd32 compat struct and freebsd32_kinfo_proc_out() are updated accordingly. PR: 293871 Reviewed by: kib MFC after: 1 week Differential revision: https://reviews.freebsd.org/D56538 lib/libkvm/kvm_proc.c | 8 ++++++++ sys/compat/freebsd32/freebsd32.h | 4 +++- sys/kern/kern_proc.c | 4 ++++ sys/sys/user.h | 4 +++- 4 files changed, 18 insertions(+), 2 deletions(-)
A commit in branch stable/15 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=ea8fd844183feb8ff44a32aa30291477e88fe4ae commit ea8fd844183feb8ff44a32aa30291477e88fe4ae Author: GenericRikka <rikka.goering@outlook.de> AuthorDate: 2026-04-20 23:32:49 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2026-04-27 01:28:59 +0000 kern/proc: expose reaper PID and subtree root in struct kinfo_proc PR: 293871 (cherry picked from commit 0f89380a3d208d67698f2d35afd35257e5fdbe09) lib/libkvm/kvm_proc.c | 8 ++++++++ sys/compat/freebsd32/freebsd32.h | 4 +++- sys/kern/kern_proc.c | 4 ++++ sys/sys/user.h | 4 +++- 4 files changed, 18 insertions(+), 2 deletions(-)
This has been committed to main and MFC'd to stable/15. Could someone with triage permissions please close this as FIXED? Thank you.