[Bug 293871] kern/proc: expose reaper PID and subtree root in struct kinfo_proc

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293871

--- Comment #7 from Generic Rikka <rikka.goering@outlook.de> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.