tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: sysctl_doeproc() race



    Date:        Sat, 10 Mar 2018 21:47:31 +0100
    From:        Kamil Rytarowski <n54%gmx.com@localhost>
    Message-ID:  <6cbea372-5520-8d76-72ac-68409f5a3c20%gmx.com@localhost>

  | This does not fix the race, 

Some races aren't worth fixing.    What is the real issue here?

  | We will end up with the same scenario that
  | allproc ones will be moving from allproc to zombieproc and we won't know
  | whether they will be counted 0 times, once or twice.

If you scan zombproc first, as Christos suggested, that reduces to 0 or once,
as, as he implied, if you have found a process on zombproc, you cannot
later find the same one on allproc.

For most user level applications that should be good enough - depending
upon what the actual interface is, you could also scan zombproc twice,
once initially, then if the process was not found after allproc has been
scanned, look on zombproc again.

But generally not finding a zombie is "normal" - as long as we find it in
some later attempt - if this time the process just happened to be in the
process of dying, and is moving from allproc to zombproc, then to the
user level, the user just won the race - looked before the process died.
When it looks next time, it will be found on zombproc.

Don't beat yourself up trying to make this kind of thing perfect, just find
a strategy that solves the actual problem, and live with it.

kre



Home | Main Index | Thread Index | Old Index