lkml.org 
[lkml]   [2014]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] cpuset: fix a locking issue in cpuset_migrate_mm()
On 2014/2/27 18:19, Li Zefan wrote:
> I can trigger a lockdep warning:
>
> # mount -t cgroup -o cpuset xxx /cgroup
> # mkdir /cgroup/cpuset
> # mkdir /cgroup/tmp
> # echo 0 > /cgroup/tmp/cpuset.cpus
> # echo 0 > /cgroup/tmp/cpuset.mems
> # echo 1 > /cgroup/tmp/cpuset.memory_migrate
> # echo $$ > /cgroup/tmp/tasks
> # echo 1 > /cgruop/tmp/cpuset.mems
>
> ===============================
> [ INFO: suspicious RCU usage. ]
> 3.14.0-rc1-0.1-default+ #32 Not tainted
> -------------------------------
> include/linux/cgroup.h:682 suspicious rcu_dereference_check() usage!
> ...
> [<ffffffff81582174>] dump_stack+0x72/0x86
> [<ffffffff810b8f01>] lockdep_rcu_suspicious+0x101/0x140
> [<ffffffff81105ba1>] cpuset_migrate_mm+0xb1/0xe0
> ...
>
> We used to hold cgroup_mutex when calling cpuset_migrate_mm(), but now
> we hold cpuset_mutex, which causes task_css() to complain.
>
> This is not a false-positive but a real issue.
>
> Holding cpuset_mutex won't prevent a task's cpuset from changing, and

I meant it won't prevent a task from migrating to another cpuset.

> it won't prevent the original task->cgroup from destroying during this
> change.




\
 
 \ /
  Last update: 2014-02-27 12:01    [W:0.049 / U:6.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site