On Fri, 2010-04-23 at 09:05 +0800, Li Zefan wrote:
>
>
> You are right in that taking task_lock() is sufficient (I forgot
> this lock rule), but it's not true that whatever locks are held
> in the ->attach method can pin a task's cgroup.
Ah, can you be more specific about the ->attach() case?
On Fri, Apr 23, 2010 at 10:35:52AM +0800, Li Zefan wrote:
> task_subsys_state() is safe under task_lock(). See
> Documentation/cgroups/cgroups.txt for locking rule.
>
> This fixes an RCU warning when resume from suspend. The
> warning comes from freezer cgroup in cgroup_freezing_or_frozen().
>
>
On Fri, Apr 23, 2010 at 10:35:52AM +0800, Li Zefan wrote:
> task_subsys_state() is safe under task_lock(). See
> Documentation/cgroups/cgroups.txt for locking rule.
>
> This fixes an RCU warning when resume from suspend. The
> warning comes from freezer cgroup in cgroup_freezing_or_frozen().
>
>
task_subsys_state() is safe under task_lock(). See
Documentation/cgroups/cgroups.txt for locking rule.
This fixes an RCU warning when resume from suspend. The
warning comes from freezer cgroup in cgroup_freezing_or_frozen().
Signed-off-by: Li Zefan
---
I'm not sure which is preferable - access
with CONFIG_PROVE_RCU, a warning can be triggered when we
resume from suspend:
...
include/linux/cgroup.h:533 invoked rcu_dereference_check() without
protection!
...
task_freezer() calls task_subsys_state(), which needs to be
protected by rcu_read_
Quoting Dan Smith (da...@us.ibm.com):
> Signed-off-by: Dan Smith
Looks good to my limited understanding.
Acked-by: Serge Hallyn
> ---
> net/checkpoint_dev.c |7 ---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/net/checkpoint_dev.c b/net/checkpoint_dev.c
> index
On Thu, Apr 22, 2010 at 02:12:12PM -0700, Matt Helsley wrote:
> On Thu, Apr 22, 2010 at 12:20:04PM +0200, Peter Zijlstra wrote:
>
>
>
> > 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 abou
On Thu, Apr 22, 2010 at 12:20:04PM +0200, Peter Zijlstra wrote:
> 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).
For my future reference, what's the right way to "fix" these
situa
On Thu, 2010-04-22 at 12:59 -0700, Paul E. McKenney wrote:
> On Thu, Apr 22, 2010 at 02:27:55PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-04-22 at 17:31 +0800, Li Zefan wrote:
> > > with CONFIG_PROVE_RCU, a warning can be triggered when we
> > > resume from suspend:
> > >
> > > ...
> > > inclu
Signed-off-by: Dan Smith
---
net/checkpoint_dev.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/checkpoint_dev.c b/net/checkpoint_dev.c
index 7ccb899..2787892 100644
--- a/net/checkpoint_dev.c
+++ b/net/checkpoint_dev.c
@@ -136,11 +136,12 @@ static struct nlms
On Thu, Apr 22, 2010 at 02:27:55PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-04-22 at 17:31 +0800, Li Zefan wrote:
> > with CONFIG_PROVE_RCU, a warning can be triggered when we
> > resume from suspend:
> >
> > ...
> > include/linux/cgroup.h:533 invoked rcu_dereference_check() without
> > protec
On Thu, Apr 22, 2010 at 05:32:28PM +0800, Li Zefan wrote:
> with CONFIG_PROVE_RCU=y, a warning can be triggered:
>
> # mount -t cgroup -o blkio xxx /mnt
> # mkdir /mnt/subgroup
>
> ...
> kernel/cgroup.c:4442 invoked rcu_dereference_check() without protection!
> ...
>
> To fix this, we avoid
On Thu, Apr 22, 2010 at 05:30:40PM +0800, Li Zefan wrote:
> 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 ei
On Thu, Apr 22, 2010 at 05:30:00PM +0800, Li Zefan wrote:
> With CONFIG_PROVE_RCU=y, a warning can be triggered:
>
> # mount -t cgroup -o memory xxx /mnt
> # mkdir /mnt/0
>
> ...
> kernel/cgroup.c:4442 invoked rcu_dereference_check() without protection!
> ...
>
> This is a false-positive. It
On Thu, Apr 22, 2010 at 05:29:24PM +0800, Li Zefan wrote:
> with CONFIG_PROVE_RCU=y, a warning can be triggered:
>
> # mount -t cgroup -o debug xxx /mnt
> # cat /proc/$$/cgroup
>
> ...
> kernel/cgroup.c:1649 invoked rcu_dereference_check() without protection!
> ...
>
> This is a false-positi
On Thu, Apr 22, 2010 at 05:32:28PM +0800, Li Zefan wrote:
> with CONFIG_PROVE_RCU=y, a warning can be triggered:
>
> # mount -t cgroup -o blkio xxx /mnt
> # mkdir /mnt/subgroup
>
> ...
> kernel/cgroup.c:4442 invoked rcu_dereference_check() without protection!
> ...
>
IIUC, so blkiocg_create
On Thu, 2010-04-22 at 17:31 +0800, Li Zefan wrote:
> with CONFIG_PROVE_RCU, a warning can be triggered when we
> resume from suspend:
>
> ...
> include/linux/cgroup.h:533 invoked rcu_dereference_check() without protection!
> ...
>
> task_freezer() calls task_subsys_state(), which needs to be
> pr
On Thu, 2010-04-22 at 17:30 +0800, Li Zefan wrote:
> 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
>
with CONFIG_PROVE_RCU=y, a warning can be triggered:
# mount -t cgroup -o blkio xxx /mnt
# mkdir /mnt/subgroup
...
kernel/cgroup.c:4442 invoked rcu_dereference_check() without protection!
...
To fix this, we avoid caling css_depth() here, which is a bit simpler
than the original code.
Signe
with CONFIG_PROVE_RCU, a warning can be triggered when we
resume from suspend:
...
include/linux/cgroup.h:533 invoked rcu_dereference_check() without protection!
...
task_freezer() calls task_subsys_state(), which needs to be
protected by rcu_read_lock or cgroup_mutex.
Signed-off-by: Li Zefan
-
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.
Signed-off-by: Li Zefan
---
kern
With CONFIG_PROVE_RCU=y, a warning can be triggered:
# mount -t cgroup -o memory xxx /mnt
# mkdir /mnt/0
...
kernel/cgroup.c:4442 invoked rcu_dereference_check() without protection!
...
This is a false-positive. It's safe to directly access parent_css->id.
Signed-off-by: Li Zefan
---
kern
with CONFIG_PROVE_RCU=y, a warning can be triggered:
# mount -t cgroup -o debug xxx /mnt
# cat /proc/$$/cgroup
...
kernel/cgroup.c:1649 invoked rcu_dereference_check() without protection!
...
This is a false-positive, because cgroup_path() can be called
with either rcu_read_lock() held or cg
23 matches
Mail list logo
