Messages in this thread | | | Date | Fri, 12 Dec 2008 11:00:44 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] sched: fix another race when reading /proc/sched_debug |
| |
* Li Zefan <lizf@cn.fujitsu.com> wrote:
> I fixed an oops with the following commit: > > | commit 24eb089950ce44603b30a3145a2c8520e2b55bb1 > | Author: Li Zefan <lizf@cn.fujitsu.com> > | Date: Thu Nov 6 12:53:32 2008 -0800 > | > | cgroups: fix invalid cgrp->dentry before cgroup has been completely removed > | > | This fixes an oops when reading /proc/sched_debug. > > The above commit fixed a race that reading /proc/sched_debug may access > NULL cgrp->dentry if a cgroup is being removed. > > But I found there's another different race, in that reading sched_debug > may access a cgroup which hasn't been completed created, and thus > dereference NULL cgrp->dentry! > > cgroup_create() > cpu_cgroup_create() > register_fair_sched_group() > list_add_rcu(...) > print_cfs_stats() > for_each_leaf_cfs_rq() > print_cfs_rq() > cgroup_path() > cgroup->dentry = dentry; > > task_group is added to the global list before the cgroup has been created > completely, if at this time print_cfs_stats() is called, it will access > the half-created cgroup. > > This patch fixes the bug by holding cgroup_lock() to wait the cgroup to > be created completely before calling cgroup_path(). > > Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
applied to tip/sched/urgent, thanks!
> The patch is based on linus's git tree, and should go into 2.6.28, > but it conflicts with the cleanup patch in sched/core: > 0a0db8f5c9d4bbb9bbfcc2b6cb6bce2d0ef4d73d
i merged it up in tip/master, could you please check whether it's ok?
Ingo
| |