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

[KAMEZAWA Hiroyuki]

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.

-Kame

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