Re: [RFC] ps command race fix

[ebiederm@xmission.com (Eric W. Biederman)]

Andrew Morton <akpm@osdl.org> writes:

> So I think we're still seeking a solution to this.
>
> Options might be:
>
> a) Pin the most-recently-visited task in some manner, so that it is
>    still on the global task list when we return.  That's fairly simple to
>    do (defer the release_task()) but it affects task lifetime and visibility
>    in rare and worrisome ways.
>
> b) Change proc_pid_readdir() so that it walks the pid_hash[] array
>    instead of the task list.  Need to do something clever when traversing
>    each bucket's list, but I'm not sure what ;) It's the same problem.
>
>    Possibly what we could do here is to permit the task which is walking
>    /proc to pin a particular `struct pid': take a ref on it then when we
>    next start walking one of the pid_hash[] chains, we _know_ that the
>    `struct pid' which we're looking for will still be there.  Even if it
>    now refers to a departed process.
>
> c) Nuke the pid_hash[], convert the whole thing to a radix-tree. 
>    They're super-simple to traverse.  Not sure what we'd index it by
>    though.
>
> I guess b) is best.

The advantage with walking the task list is new entries are always added
at the end.  Neither of the other two proposed orders does that.  So
in fact I think the problem will get worse leaving more tasks skipped,
because in those cases new tasks can be inserted before our cursor in
the list.  The proposed snapshot implementation has a similar problem
in that new process could get skipped.

The simplest version I can think of is to place a cousin of the
tasklist into struct pid.  Allowing us to use a very similar
algorithm to what we use now.  But since we can pin struct pid we
won't have the chance of our current position being deleted.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/