Re: [RFC] ps command race fix

From: KAMEZAWA Hiroyuki
Date: Thu Aug 17 2006 - 02:27:45 EST

On Wed, 16 Aug 2006 22:59:50 -0600
ebiederm@xxxxxxxxxxxx (Eric W. Biederman) wrote:

> So I just threw something together that seems to work.
> All of the pid are listed in order and the next used pid is found by
> scanning the pid bitmap.
> Scanning the pid bitmap might be a little heavy but actually is likely
> quite cache friendly as the accesses are extremely predictable, and
> everything should fit into 64 cache lines, which is fewer cache lines
> than walking a tree, and more predictable. Of course I turn around
> and then do a hash table lookup which is at least one more cache line
> and probably an unpredictable one at that.
> The point despite the brute force nature I have no reason to suspect
> this will run any noticeably slower than the current implementation.
> Look at this try it out and if this solves the problem we can push
> this upstream.
At first, Thanks.


task = get_pid_task(find_next_pid(tgid), PIDTYPE_PID);

Does this return only "task/process" ? and never return "thread" ?

My another concern is that newly-created-process while ps running cannot be catched
by this kind of "table walking" approach (as my previous work)
But if people say O.K, I have no complaint.

I(we)'ll post another list-based one in the next week, anyway.
(I can't go-ahead this week...)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at