On Mon, Aug 15, 2016 at 11:50:04AM +0300, Cyrill Gorcunov wrote: > On Mon, Aug 15, 2016 at 12:45:46AM +0200, Jann Horn wrote: > > > > > > > > That's pretty much inherent when you're inspecting a moving system - by the > > > > time you've collected your information, it might be stale. So what? > > > > > > What "what"? I told you that the information you fetch from running system > > > only valid when kernel does its work, once you jump back to userspace > > > the information might not be valid anymore. And the @children does the > > > same: in native procfs read you may miss freshly created processes, > > > in @children read you may miss exited processes. It's the same nature. > > > > "in @children read you may miss exited processes"? If that was the extent of it, > > everything would be fine. But that's not what's happening. Read the comment in > > get_children_pid(): > > > > * We might miss some children here if children > > * are exited while we were not holding the lock, > > * but it was never promised to be accurate that > > * much. > > * > > * "Just suppose that the parent sleeps, but N children > > * exit after we printed their tids. Now the slow paths > > * skips N extra children, we miss N tasks." (c) > > > > "skips N extra children". *NOT* necessarily the same N children that exited, but > > also children that were running before you started reading the "children" file > > and are still running afterwards. > > I happen to know how this code work, i've been writting it. And it's the same > as reading plain pids: you might miss freshly created pids completely until > the re-read. The rule of thumb is to re-validate the results, always, or > stop the processes first. Ah, I think maybe I understad what you're saying. If you want a list of PIDs that includes all stable children of a given running process, you have to read the "children" file in a loop until two reads return the same list, using the fact that the children are ordered by the time they became children of the target process and therefore the read following a read that triggered the slowpath always returns something different unless all children following the position that triggered the slowpath are replaced? Or something like that? (If you just read "children" without the loop-until-stable rule, as far as I can tell, no amount of revalidation will prevent you from missing dropped children.)
Attachment:
signature.asc
Description: Digital signature
