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

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

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

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Robert Elz <kre%munnari.OZ.AU@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/60962: fork and spawn read p_pgrp without proc_lock
Date: Thu, 5 Nov 2026 08:27:29 +0000

 > Date: Thu, 05 Nov 2026 07:10:17 +0700
 > From: Robert Elz <kre%munnari.OZ.AU@localhost>
 >=20
 > 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
 >=20
 > 	1. fork in one thread
 > 	2. setsid/setpgid in another thread
 > 	3. ???
 >=20
 > might just as easily be
 >=20
 > 	1. setsid/setpgid in one thread
 > 	2. fork in another thread
 > 	3. ???
 >=20
 > and I don't believe
 >=20
 > 	4. profit!
 >=20
 > 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 =3D 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?