From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759322Ab2INJX3 (ORCPT ); Fri, 14 Sep 2012 05:23:29 -0400 Received: from mail-bk0-f46.google.com ([209.85.214.46]:59413 "EHLO mail-bk0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758462Ab2INJX1 (ORCPT ); Fri, 14 Sep 2012 05:23:27 -0400 Message-ID: <5052F78A.7010007@suse.cz> Date: Fri, 14 Sep 2012 11:23:22 +0200 From: Jiri Slaby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: aris@redhat.com CC: Andrew Morton , Linux kernel mailing list , Tejun Heo , lizefan@huawei.com, containers@lists.linux-foundation.org, cgroups@vger.kernel.org, Jiri Slaby Subject: include/linux/cgroup.h:553 suspicious rcu_dereference_check() usage! X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, with current -next trees and LDEP enabled, I'm getting: =============================== [ INFO: suspicious RCU usage. ] 3.6.0-rc5-next-20120913+ #42 Not tainted ------------------------------- /home/latest/linux/include/linux/cgroup.h:553 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 2 locks held by kdevtmpfs/23: #0: (sb_writers){.+.+.+}, at: [] mnt_want_write+0x1f/0x50 #1: (&sb->s_type->i_mutex_key#3/1){+.+.+.}, at: [] kern_path_create+0x7f/0x170 stack backtrace: Pid: 23, comm: kdevtmpfs Not tainted 3.6.0-rc5-next-20120913+ #42 Call Trace: [] lockdep_rcu_suspicious+0xfd/0x130 [] devcgroup_inode_mknod+0x19d/0x240 [] ? ns_capable+0x44/0x80 [] vfs_mknod+0x71/0xf0 [] handle_create.isra.2+0x72/0x200 [] devtmpfsd+0x114/0x140 [] ? handle_create.isra.2+0x200/0x200 [] kthread+0xd6/0xe0 [] kernel_thread_helper+0x4/0x10 [] ? retint_restore_args+0xe/0xe [] ? kthread_create_on_node+0x140/0x140 [] ? gs_change+0xb/0xb It's due to the commit "device_cgroup: convert device_cgroup internally to policy + exceptions". It removed rcu locks which are needed in task_devcgroup called in this chain: devcgroup_inode_mknod OR __devcgroup_inode_permission -> __devcgroup_inode_permission -> task_devcgroup -> task_subsys_state -> task_subsys_state_check. regards, -- js suse labs