Re: pg_jobc going negative?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> [... pg_jobc ...]

> I see 3 ways forward...

I count 4, but maybe kre is counting two of them as subclasses of a
single one.

> simply drop the KASSERT the way that FreeBSD have done, and let
> things return to the semi-broken but rarely bothersome code that was
> there before.

> Or, we could properly define what pg_jobc is counting, and then make
> sure that it counts whatever that is properly [...]

> Another (more radical) approach would be to simply drop orphanpg()
> completely, and thus no longer need pg_jobc at all.

> Third, and the option I'd suggest, is to revert to more basic
> principles, remove the pg_jobc attempt to detect when a session
> leader has exited, or changed to a different process group, and
> instead at candidate events (any time a process leaves a process
> group, for any reason) check if that process was the session leader,
> and if it is, clean up any now orphaned stopped processes.

Not surprisingly in view of who put it forward, I would agree with this
suggestion.

But that alone isn't worth an email.  The main thing prompting me to
write this mail is

> We can even leave pg_jobc in the pgrp struct, to avoid needing a
> kernel version bump (and for reasons I cannot imagine, pg_jobc is
> copied into kinfo and einfo structs for sysctl and /proc access to
> the process data, so leaving it around avoids needing to version
> those interfaces as well ... the value would be a meaningless 0,
> always, but I really find it hard to believe that anything would ever
> care, or even notice).

It seems to me that if pg_jobc is exported, someone presumably once
cared and there's thus a decent chance someone still cares.

Did you do a sweep for userland references to it?  It seems plausible
to me that it's used, at least for zero/nonzero, by userland tools that
are interested in process groups.

Is there any record of who added the code to export pg_jobc to
userland?  If so, and if that person is still around, it might be worth
sending a question thataway to see if any explanation might be
forthcoming.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B