Messages in this thread | | | Date | Mon, 15 Dec 2008 10:11:57 +0800 | From | Li Zefan <> | Subject | Re: [PATCH] sched: fix another race when reading /proc/sched_debug |
| |
KAMEZAWA Hiroyuki wrote: > On Mon, 15 Dec 2008 09:39:18 +0800 > Li Zefan <lizf@cn.fujitsu.com> wrote: > >> Paul Menage wrote: >>> I sent out some patches last week (search for hierarchy_mutex) that would >>> mean that you'd only need to take a subsystem-local lock to keep a cgroup >>> alive. People seemed to like them so I'll tweak them based on feedback and >>> send them on to Andrew. >>> >> Unfortunately, AFAICS the proposed hierarchy_mutex can't solve this bug. :( >> > Hmm ? how about this way if cgroup->dentry is problem ? >
Sounds feasable, though the resulting code might a bit tricky.
> at creation: > - cpu_cgroup_populate() should record "tg" that "this cgroup has valid dentry"
This avoids /proc/sched_debug accessing invalid cgrp dentry while a cgroup is being created.
> at deletion > - css_tryget() will be useful to avoid the race.
And this avoids accessing a dead task_group.
Since css_tryget() is a 2.6.29 material, I think we can have this bug fixed for 2.6.28 by holding cgroup_lock, and try to remove the global lock for 2.6.29 ?
| |