Re: sysctl_doeproc() race

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 11 Mar 2018 16:02:57 +0100
    From:        Kamil Rytarowski <n54%gmx.com@localhost>
    Message-ID:  <10b0efe2-35bb-d1e8-ed28-587f643bdfd7%gmx.com@localhost>

  | We already use markers so I prefer to stick to this solution and it
  | makes this code reliable.

Actually, since I sent the previous message, I have been thinking on it
more, and I don't think that it does.

It handles the case where we have found a process on allproc, and it is
(while we are scanning more of allproc) moved to zombproc, so we won't
get the process twice.

But it doesn't handle the case of a process that is moved off allproc, onto
zombproc, after we have started the scan, but before encountining that
process.

In that case, the process will simply be skipped.   In all cases except
KERN_PROC_PID I'd prefer to have the data twice, than never, for
processes that still exist - that's a far better result for most users I think.

The KERN_PROC_PID where we want to find the process exactly once is
better handled by simply short circuiting the loop after the process is
found, wherever it is found.

Something like (untested)

	if (op == KERN_PROC_PID && elem_count == 0)
		break;

right at the bottom of the loop (after the "Release reference to process." 
code)  I don't see that it matters whether it is KERN_PROC (wjere
elem_count is always 0) or KERN_PROC2 (where it counts down)
for this. 

That does mean that someone can request KERN_PROC_PID with an
element_count of 2 if they are actually looking for the case where a
process is moving from allproc to zombproc to see the state both before
and after it was zombified (it wiould have to get *real* lucky) if it
wanted (in the KERN_PROC2 case anyway).   That seems reasonable...

kre