Messages in this thread | | | Date | Tue, 25 Jul 2006 10:53:39 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [RFC] ps command race fix |
| |
On Mon, 24 Jul 2006 18:20:00 -0700 Andrew Morton <akpm@osdl.org> wrote: > > It allocates a potentially-significant amount of memory per-task, until > that tasks exits (we could release it earlier, but the problem remains) and > it adds yet another global lock in the process exit path. > I see.
> > 5 files changed, 138 insertions(+), 62 deletions(-) > > And it adds complexity and code. > > 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. >
I tried b) at the first place. but it was not very good because proc_pid_readdir() has to traverse all pids, not tgids. So, I had to access task_struct of the pid. I wanted to avoid to access task struct itself, my patch implemented a table made only from tgids.
But as you say, my patch is much intrusive. I'll dig this more. thank you for advise.
Thanks, -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/
| |