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

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> 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