Re: [RFC][PATCH] ps command race fix take2 [1/4] list token

From: KAMEZAWA Hiroyuki
Date: Wed Aug 23 2006 - 08:46:45 EST

On Wed, 23 Aug 2006 05:35:08 -0600
ebiederm@xxxxxxxxxxxx (Eric W. Biederman) wrote:

> What you are proposing is to reduce contention by having several different
> locks for each of the global data structures.
not for each, just a lock for a list for for_each_process ;)
About cache bounsing, it's problem if heavy.
In my plan, fork/exit/proc_readdir will have write lock of
for_each_process_write_lock. talking this again after take3 will be good.
If I'm very lucky, I'll find some another way..

> >> >> In addition you only solves half the readdir problems. You don't solve
> >> >> the seek problem which is returning to an offset you had been to
> >> >> before. A relatively rare case but...
> >> >>
> >> > Ah, I should add lseek handler for proc root. Okay.
> >>
> >> Hmm. Possibly. Mostly what I was thinking is that a token in the
> >> list simply cannot solve the problem of a guaranteeing lseek to a
> >> previous position works. I really haven't looked closely on
> >> how you handle that case.
> >>
> > I'll try some. But lseek on directory, which is modified at any moment, cannot
> > work stable anyway.
> It can work as well as anything else in readdir. It can ensure that you don't
> miss things that haven't been added or deleted during the while you are in
> the middle of readdir. I'm just after the usual Single Unix Spec/POSIX guarantees.
> The same thing that are missing in the current readdir implementation.
BTW, what position means at lseek() in directory ?
bytes ? implementation dependent ?

I'm thinking of implementing "position" as offset in task list.
Hmm..about lseek(), it's obvious that searching in a table has an advantage.
we cannot define position with list.
What will you do if user moves f->pos to not-used-position.

I have no complaint about pidmap scanning next_tgid() unless it doesn't scan
all over the world.


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