Re: kern/60962: fork and spawn read p_pgrp without proc_lock

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

> Date: Thu, 05 Nov 2026 07:10:17 +0700
> From: Robert Elz <kre%munnari.OZ.AU@localhost>
> 
> It looks to me there's an inherent race in the situation described,
> anyway, given the 2 threads running, one doing a fork() the other
> setsid() or setpgid(), the situation described
> 
> 	1. fork in one thread
> 	2. setsid/setpgid in another thread
> 	3. ???
> 
> might just as easily be
> 
> 	1. setsid/setpgid in one thread
> 	2. fork in another thread
> 	3. ???
> 
> and I don't believe
> 
> 	4. profit!
> 
> applies at all.   This is a simple code bug in the application.
> If it cares what sid or pgrp the child gets, it shouldn't be
> altering those things at or around the time of the fork().

No disagreement here.

> Further, I don't think the change you made really alters anything,
> or not anything significant, if anything it makes it slightly more
> likely that the race will go the way of the fork'd child getting the
> pgrp from after the change (but obviously can't guarantee that, as in
> the first of the two scenarios above, 1 might be finished before 2 starts).

Suppose parent (p1) is in pgrp 42 and switches to pgrp 54.

Now child (p2) has p2->p_pgrp = pgrp42, but

	LIST_INSERT_AFTER(p2, p1, p_pglist)

puts it on the pgrp54->pg_members list.  What happens when the last
process in pgrp 42 exits, and someone tries to dereference
p2->p_pgrp->(anything), e.g. by calling kill(0, sig) or
getpriority(PRIO_PGRP) or whatever?