From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Re: [PATCH] cgroup: missing rcu read lock around task_css_set Date: Mon, 03 Mar 2014 17:43:11 -0500 Message-ID: <5315057F.3030602@oracle.com> References: <1393729211-937-1-git-send-email-sasha.levin@oracle.com> <20140303223327.GB26523@mtj.dyndns.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140303223327.GB26523-9pTldWuhBndy/B6EtB590w@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Tejun Heo Cc: lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On 03/03/2014 05:33 PM, Tejun Heo wrote: > On Sat, Mar 01, 2014 at 10:00:11PM -0500, Sasha Levin wrote: >> rcu read lock should be held when calling and working with task_css_set. >> >> This patch also fixes a related lockdep warning. > > Hmmm... PF_EXITING should be visible at that point and cset can't > change anymore. We prolly need to update lockdep annotation rather > than adding spurious rcu locking around it. Against which branch is > it? Can you please post the lockdep warning? I see it on -next. [ 0.370543] =============================== [ 0.371030] [ INFO: suspicious RCU usage. ] [ 0.371453] 3.14.0-rc4-next-20140303-sasha-00012-g35a2897-dirty #43 Not tainted [ 0.372223] ------------------------------- [ 0.372627] include/linux/cgroup.h:692 suspicious rcu_dereference_check() usage! [ 0.373417] [ 0.373417] other info that might help us debug this: [ 0.373417] [ 0.374223] [ 0.374223] rcu_scheduler_active = 1, debug_locks = 1 [ 0.374993] no locks held by swapper/0/0. [ 0.375422] [ 0.375422] stack backtrace: [ 0.375865] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc4-next-20140303-sasha-00012-g35a2897-dirty #43 [ 0.376936] 0000000000000001 ffffffff85e01d58 ffffffff8446a933 0000000000000001 [ 0.377753] ffffffff85e2e4a0 ffffffff85e01d88 ffffffff811a6ddb 0000000000000000 [ 0.380550] ffff88052a2398a8 ffff88052a238000 0000000000000000 ffffffff85e01de8 [ 0.381370] Call Trace: [ 0.381641] [] dump_stack+0x52/0x7f [ 0.382261] [] lockdep_rcu_suspicious+0x10b/0x120 [ 0.382893] [] cgroup_exit+0x20d/0x250 [ 0.383566] [] ? ktime_get_ts+0x145/0x1d0 [ 0.384221] [] copy_process+0x5d6/0x670 [ 0.384850] [] do_fork+0x8b/0x2e0 [ 0.385347] [] ? trace_hardirqs_on+0xd/0x10 [ 0.386009] [] ? mutex_unlock+0xe/0x10 [ 0.386559] [] ? early_idt_handlers+0x117/0x120 [ 0.387327] [] kernel_thread+0x26/0x30 [ 0.387947] [] rest_init+0x26/0x150 [ 0.388491] [] start_kernel+0x3c0/0x3c7 [ 0.389126] [] ? repair_env_string+0x5b/0x5b [ 0.389813] [] ? memblock_reserve+0x49/0x4e [ 0.390019] [] x86_64_start_reservations+0x2a/0x2c [ 0.390754] [] x86_64_start_kernel+0x186/0x195 Thanks, Sasha