1. 06 May, 2010 1 commit
  2. 04 May, 2010 7 commits
    • Paul E. McKenney's avatar
      memcg: css_id() must be called under rcu_read_lock() · ad4ba375
      Paul E. McKenney authored
      This patch fixes task_in_mem_cgroup(), mem_cgroup_uncharge_swapcache(),
      mem_cgroup_move_swap_account(), and is_target_pte_for_mc() to protect
      calls to css_id().  An additional RCU lockdep splat was reported for
      memcg_oom_wake_function(), however, this function is not yet in
      mainline as of 2.6.34-rc5.
      Reported-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
      Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
      Signed-off-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Tested-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      ad4ba375
    • Li Zefan's avatar
      cgroup: Check task_lock in task_subsys_state() · 1ce7e4ff
      Li Zefan authored
      Expand task_subsys_state()'s rcu_dereference_check() to include the full
      locking rule as documented in Documentation/cgroups/cgroups.txt by adding
      a check for task->alloc_lock being held.
      
      This fixes an RCU false positive when resuming from suspend. The warning
      comes from freezer cgroup in cgroup_freezing_or_frozen().
      Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Acked-by: default avatarMatt Helsley <matthltc@us.ibm.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      1ce7e4ff
    • Li Zefan's avatar
      sched: Fix an RCU warning in print_task() · b629317e
      Li Zefan authored
      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.
      
      The rcu_dereference_check() does include cgroup_lock_is_held(), so we
      know that this lock is not held.  Therefore, in a CONFIG_PREEMPT kernel,
      to say nothing of a CONFIG_PREEMPT_RT kernel, the original code could
      have ended up copying a string out of the freelist.
      
      This patch inserts RCU read-side primitives needed to prevent this
      scenario.
      Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      b629317e
    • Li Zefan's avatar
      cgroup: Fix an RCU warning in alloc_css_id() · fae9c791
      Li Zefan authored
      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: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      fae9c791
    • Li Zefan's avatar
      cgroup: Fix an RCU warning in cgroup_path() · 9a9686b6
      Li Zefan authored
      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 cgroup_mutex held.
      Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      9a9686b6
    • David Howells's avatar
      KEYS: Fix an RCU warning in the reading of user keys · e35ec2d2
      David Howells authored
      Fix an RCU warning in the reading of user keys:
      
      ===================================================
      [ INFO: suspicious rcu_dereference_check() usage. ]
      ---------------------------------------------------
      security/keys/user_defined.c:202 invoked rcu_dereference_check() without protection!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 1, debug_locks = 0
      1 lock held by keyctl/3637:
       #0:  (&key->sem){+++++.}, at: [<ffffffff811a80ae>] keyctl_read_key+0x9c/0xcf
      
      stack backtrace:
      Pid: 3637, comm: keyctl Not tainted 2.6.34-rc5-cachefs #18
      Call Trace:
       [<ffffffff81051f6c>] lockdep_rcu_dereference+0xaa/0xb2
       [<ffffffff811aa55f>] user_read+0x47/0x91
       [<ffffffff811a80be>] keyctl_read_key+0xac/0xcf
       [<ffffffff811a8a06>] sys_keyctl+0x75/0xb7
       [<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      e35ec2d2
    • David Howells's avatar
      KEYS: Fix an RCU warning · bfeb0360
      David Howells authored
      Fix the following RCU warning:
      
      ===================================================
      [ INFO: suspicious rcu_dereference_check() usage. ]
      ---------------------------------------------------
      security/keys/request_key.c:116 invoked rcu_dereference_check() without protection!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 1, debug_locks = 0
      1 lock held by keyctl/5372:
       #0:  (key_types_sem){.+.+.+}, at: [<ffffffff811a4e3d>] key_type_lookup+0x1c/0x70
      
      stack backtrace:
      Pid: 5372, comm: keyctl Not tainted 2.6.34-rc3-cachefs #150
      Call Trace:
       [<ffffffff810515f8>] lockdep_rcu_dereference+0xaa/0xb2
       [<ffffffff811a9220>] call_sbin_request_key+0x156/0x2b6
       [<ffffffff811a4c66>] ? __key_instantiate_and_link+0xb1/0xdc
       [<ffffffff811a4cd3>] ? key_instantiate_and_link+0x42/0x5f
       [<ffffffff811a96b8>] ? request_key_auth_new+0x17b/0x1f3
       [<ffffffff811a8e00>] ? request_key_and_link+0x271/0x400
       [<ffffffff810aba6f>] ? kmem_cache_alloc+0xe1/0x118
       [<ffffffff811a8f1a>] request_key_and_link+0x38b/0x400
       [<ffffffff811a7b72>] sys_request_key+0xf7/0x14a
       [<ffffffff81052227>] ? trace_hardirqs_on_caller+0x10c/0x130
       [<ffffffff81393f5c>] ? trace_hardirqs_on_thunk+0x3a/0x3f
       [<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
      
      This was caused by doing:
      
      	[root@andromeda ~]# keyctl newring fred @s
      	539196288
      	[root@andromeda ~]# keyctl request2 user a a 539196288
      	request_key: Required key not available
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      bfeb0360
  3. 30 Apr, 2010 2 commits
  4. 23 Apr, 2010 10 commits
  5. 22 Apr, 2010 20 commits