Messages in this thread | | | Date | Wed, 23 Aug 2006 21:46:40 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [RFC][PATCH] ps command race fix take2 [1/4] list token |
| |
On Wed, 23 Aug 2006 05:35:08 -0600 ebiederm@xmission.com (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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |