1. 05 5月, 2010 3 次提交
    • L
      cgroup: Fix an RCU warning in cgroup_path() · 9a9686b6
      Li Zefan 提交于
      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: NLi Zefan <lizf@cn.fujitsu.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      9a9686b6
    • D
      KEYS: Fix an RCU warning in the reading of user keys · e35ec2d2
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      e35ec2d2
    • D
      KEYS: Fix an RCU warning · bfeb0360
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      bfeb0360
  2. 30 4月, 2010 2 次提交
  3. 23 4月, 2010 32 次提交
  4. 22 4月, 2010 3 次提交