On 10.03.2018 23:49, Robert Elz wrote: > 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? > The real issue is that polling for a process returns two entities of the same process and this was overflowing a buffer in application, prepared for a single result. > | 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. > We keep relocking proc_lock, and a zombie might be consumed by its parent and later its body reused for a new process. We will end up with a return result with two processes with the same pid. > 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. > I've been trying to check the POSIX specification for this case, and it's uncovered. Process lifetime is specified for the episode of being alive and zombie, without the transition bits, except internal details about exit status etc. A process polling of interfaces is reliable only for the parent and unreliable for others. I think your narration that during a transition a process might disappear is legitimate. > 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. > I will recheck the patch of mine with ATF as I think it's the best approach for these circumstances. We will see 0 or 1 entries. New zombies and new processes appended to allproc and zombproc will be undetected. If I would want to start from zombproc I would need to add a marker for allproc. > kre >
Attachment:
signature.asc
Description: OpenPGP digital signature