PR/55665 CVS commit: src/sys/kern

["Robert Elz" <kre%netbsd.org@localhost>]

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

From: "Robert Elz" <kre%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/55665 CVS commit: src/sys/kern
Date: Thu, 2 Apr 2026 11:36:24 +0000

 Module Name:	src
 Committed By:	kre
 Date:		Thu Apr  2 11:36:24 UTC 2026
 
 Modified Files:
 	src/sys/kern: kern_proc.c
 
 Log Message:
 PR kern/60159 PR kern/55665  pg_jobc assertions unsafe
 
 It has long been known that the way that the pg_jobc field in
 struct pgrp works (or doesn't perhaps) is understood by no-one,
 yet it does seem to function.
 
 Its (sole) purpose is to determine whether a process group should
 be subject to terminal generated stop signals (SIGTSTP, SIGTTIN, SIGTTOU).
 
 That is, if there is no parent process of any of the jobs in the
 process group, which is in a different process group than the one in
 question (or it would also be affected by the signal) which can arrange
 to send a SIGCONT to the process group to restart it, or some other
 signal to terminate it, then the kernel must not stop that process
 group, or it would (could) remained stopped, orphaned, forever (or
 until some human notices and manually kills it, using some signal or
 other).
 
 However, the extremely convoluted calculations required to maintain
 pg_jobc, which is constantly being updated as processes are created,
 terminate, or change process groups, is not really a rational way to
 handle this.   Much better is to simply check (when about to send the
 signal) and locate a suitable parent process which could restart the
 group if stopped.   That's simple, clean, and happens only when one
 of those terminal generated signals is to be sent.
 
 Eventually the kernel will be changed to work that way.
 
 However, there seems to be no urgency - pg_jobc as we have it
 now seems to function correctly, even though no-one really knows
 how (or no-one I am aware of) and any attempt to assert anything
 about its value "this simply has to be true" generally turns out
 to be false.   That is almost certainly what happened in this case.
 (kern/60159) and used to happen even more frequently in the older
 case (kern/55665).
 
 The assertion that caused 55665 was removed (commented out) in Sep 2020.
 However one was left (the one triggered in kern/60159), so let's just
 do away with that one for now too.
 
 The only possible problem that can be caused by pg_jobc malfunctions
 are orphaned process groups - which no-one ever seems to actually see,
 so worrying unduly about what race conditions might exist which allow
 the value to sometimes become what should be impossible doesn't seem
 to be a productive use of anyone's time.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.281 -r1.282 src/sys/kern/kern_proc.c
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.