On Thu, 2010-04-22 at 17:30 +0800, Li Zefan wrote:
quoted text
> With CONFIG_PROVE_RCU=y, a warning can be triggered:
> 
>   $ cat /proc/sched_debug
> 
> ...
> kernel/cgroup.c:1649 invoked rcu_dereference_check() without protection!
> ...
> 
> Both cgroup_path() and task_group() should be called with either
> rcu_read_lock or cgroup_mutex held.

Well, that's not strictly true, but yes in this case it appears to be a
genuine race, since only tasklist_lock is held and that doesn't protect
us from the task changing groups (and thus the current group from going
away on us).

You can also pin a cgroup by holding whatever locks are held in the
->attach method. But the RCU annotation doesn't know (nor reasonably can
know about that).

quoted text
> Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
> ---
>  kernel/sched_debug.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/sched_debug.c b/kernel/sched_debug.c
> index 9cf1baf..87a330a 100644
> --- a/kernel/sched_debug.c
> +++ b/kernel/sched_debug.c
> @@ -114,7 +114,9 @@ print_task(struct seq_file *m, struct rq *rq, struct task_struct *p)
>  	{
>  		char path[64];
>  
> +		rcu_read_lock();
>  		cgroup_path(task_group(p)->css.cgroup, path, sizeof(path));
> +		rcu_read_unlock();
>  		SEQ_printf(m, " %s", path);
>  	}
>  #endif



--
unsubscribe notice
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/