[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100124232512.GA12383@linux.vnet.ibm.com>
Date: Sun, 24 Jan 2010 15:25:12 -0800
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: menage@...gle.com
Cc: linux-kernel@...r.kernel.org
Subject: locking design for task_subsys_state()?
Hello, Paul!
The "git blame" tool tells me that I should ask you about
task_subsys_state(), which contains an rcu_dereference() that I am trying
to instrument for lockdep-enabled RCU. I currently have it marked as
needing to either be within an RCU read-side critical section or having
the cgroup lock held. But the following splat from my lockdep enablement
leads me to believe that I also need to check for a task that is in the
process of being created.
Is there some flag in the task structure that I should check in order to
suppress this splat, and, more important, to document the locking
design? Here is what I currently have in my local tree:
static inline struct cgroup_subsys_state *task_subsys_state(
struct task_struct *task, int subsys_id)
{
return rcu_dereference_check(task->cgroups->subsys[subsys_id],
rcu_read_lock_held() ||
cgroup_lock_is_held());
}
My guess is that I should be able to add a check of one of the task
structure's flags or pointers, but thought I should ask the expert
instead of inflicting my subtly wrong guesses on you all. ;-)
Thanx, Paul
------------[ cut here ]------------
Badness at include/linux/cgroup.h:492
NIP: c0000000000c9804 LR: c0000000000c97ec CTR: c0000000000a241c
REGS: c000000000a174a0 TRAP: 0700 Not tainted (2.6.33-rc4-autokern1)
MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 84000022 XER: 00000004
TASK = c0000000008cecc0[0] 'swapper' THREAD: c000000000a14000 CPU: 0
GPR00: 0000000000000001 c000000000a17720 c000000000a15378 0000000000000000
GPR04: c0000000008edc88 0000000000000006 0000000000000001 c000000001406e70
GPR08: 0000000000000002 c000000001275171 c0000000008cf5a0 c0000000008cecc0
GPR12: 8000000000009032 c000000000a33480 0000000002100000 c000000000776300
GPR16: c000000000774a00 0000000000000000 0000000000000000 0000000000000000
GPR20: c000000000a17b60 c000000000a17de0 c0000002d3ff8140 0000000000000000
GPR24: 0000000000800b00 0000000000000000 c0000000e6668000 0000000000000000
GPR28: c0000000e6003000 fffffffffffffff4 c000000000968a68 c0000000008cecc0
NIP [c0000000000c9804] .current_cpuset_is_being_rebound+0x5c/0xa8
LR [c0000000000c97ec] .current_cpuset_is_being_rebound+0x44/0xa8
Call Trace:
[c000000000a17720] [c0000000000c97ec] .current_cpuset_is_being_rebound+0x44/0xa8 (unreliable)
[c000000000a177a0] [c0000000001453ac] .__mpol_dup+0x48/0xb8
[c000000000a17850] [c00000000006ae2c] .copy_process+0x5f4/0x1248
[c000000000a17950] [c00000000006bf20] .do_fork+0x198/0x444
[c000000000a17a80] [c000000000012ce8] .sys_clone+0x5c/0x74
[c000000000a17af0] [c000000000008788] .ppc_clone+0x8/0xc
--- Exception: c00 at .kernel_thread+0x28/0x70
LR = .rest_init+0x34/0x120
[c000000000a17de0] [c000000000875a34] .proc_sys_init+0x20/0x64 (unreliable)
[c000000000a17e50] [c000000000009a68] .rest_init+0x20/0x120
[c000000000a17ee0] [c000000000854a8c] .start_kernel+0x480/0x4a4
[c000000000a17f90] [c0000000000083ac] .start_here_common+0x1c/0x70
Instruction dump:
e87e8028 4bfddbed 60000000 2fa30000 409e0038 4bff7a29 60000000 2fa30000
409e0028 e93e8040 88090000 68000001 <0b000000> 2fa00000 41be0010 e93e8040
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists