Re: kern/59175: posix_spawn hang, hanging other process too

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/59175; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: 
Cc: Thomas Klausner <wiz%NetBSD.org@localhost>
Subject: Re: kern/59175: posix_spawn hang, hanging other process too
Date: Fri, 14 Mar 2025 15:14:37 +0000

 > Date: Fri, 14 Mar 2025 14:28:38 +0000
 > From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
 > 
 > 1. do_posix_spawn in the parent p1 creates a process p2 with
 >    proc_alloc, which has:
 >    - p2->p_stat = SIDL (can't be looked up with proc_find)
 >    - p2->p_vmspace = &vmspace0 (initial vmspace, kernel's) or NULL
 >    - p2->p_psstrp = garbage from recycled struct proc or NULL
 > 
 >    In particular, if p2 is freshly allocated, it will have null
 >    p_vmspace and p_psstrp; if it was recycled, p_vmspace will have
 >    been set to proc0.p_vmspace=&vmspace0 shortly before recycling
 >    in uvm_proc_exit:
 >    https://nxr.netbsd.org/xref/src/sys/uvm/uvm_glue.c?r=1.182#414
 
 Tiny correction: do_posix_spawn always initializes p2->p_vmspace to
 proc0.p_vmspace, i.e., &vmspace0, so NULL is not possible here, as of
 kern_exec.c rev. 1.348.
 
 This doesn't affect the rest of the analysis, nor my tentative
 conclusion that the early-parent-wakeup path is essentially unsound.
 Maybe it is workable if we tweak users of p_vmspace to act as if
 proc_find had failed but that sounds like a lot of work and also
 dicey; surely if kill(pid, 0) works then so should anything else like
 sysctls to query process stuff.
 
 Potentially relevant historical PRs:
 
 - https://gnats.NetBSD.org/46286 posix_spawn induced panic
 - https://gnats.NetBSD.org/50330 spawn_return alters p_stat without
   updating p_nstopchild
 - https://gnats.NetBSD.org/54786 Panic triggered by
   posix_spawn_kill_spawner test case