From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752432AbYFURjT (ORCPT ); Sat, 21 Jun 2008 13:39:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751563AbYFURjI (ORCPT ); Sat, 21 Jun 2008 13:39:08 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]:22010 "EHLO ug-out-1314.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751518AbYFURjF (ORCPT ); Sat, 21 Jun 2008 13:39:05 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent:from; b=blk/2rJ9ROC61xM7UDBEtY3Uc2s08BvQb4CntHNmBaQOd0UA39NwsIPn+mnHSGXKIv AcFui2Kmnd5q/Z+4N0eQbR15ScosrhIBFI2lVNZ4VUwBNB0L+F2yBbn9hGgVwUzCsaJb t/YuD9FMDelcSQPMyMuhzS84Vpimkah6cglO4= Date: Sat, 21 Jun 2008 19:38:59 +0200 To: Paul Menage , containers@lists.linux-foundation.org Cc: linux-kernel@vger.kernel.org Subject: v2.6.26-rc7/cgroups: circular locking dependency Message-ID: <20080621173859.GA6846@damson.getinternet.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) From: Vegard Nossum Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, I decided to see what cgroups is all about, and followed the instructions in Documentation/cgroups.txt :-) It happened when I did this: [root@damson /dev/cgroup/Vegard 0] # echo 1 > cpuset.cpus I can also provide the kernel config if necessary. Vegard ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.26-rc7 #25 ------------------------------------------------------- bash/10032 is trying to acquire lock: (&cpu_hotplug.lock){--..}, at: [] get_online_cpus+0x2c/0x40 but task is already holding lock: (cgroup_mutex){--..}, at: [] cgroup_lock+0xf/0x20 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (cgroup_mutex){--..}: [] __lock_acquire+0xf45/0x1040 [] lock_acquire+0x98/0xd0 [] mutex_lock_nested+0xb1/0x300 [] cgroup_lock+0xf/0x20 [] cpuset_handle_cpuhp+0x20/0x180 [] notifier_call_chain+0x37/0x70 [] __raw_notifier_call_chain+0x19/0x20 [] _cpu_down+0x78/0x240 [] cpu_down+0x2b/0x40 [] store_online+0x39/0x80 [] sysdev_store+0x2b/0x40 [] sysfs_write_file+0xa2/0x100 [] vfs_write+0x96/0x130 [] sys_write+0x3d/0x70 [] sysenter_past_esp+0x78/0xd1 [] 0xffffffff -> #0 (&cpu_hotplug.lock){--..}: [] __lock_acquire+0xaf5/0x1040 [] lock_acquire+0x98/0xd0 [] mutex_lock_nested+0xb1/0x300 [] get_online_cpus+0x2c/0x40 [] rebuild_sched_domains+0x7d/0x3a0 [] cpuset_common_file_write+0x204/0x440 [] cgroup_file_write+0x67/0x130 [] vfs_write+0x96/0x130 [] sys_write+0x3d/0x70 [] sysenter_past_esp+0x78/0xd1 [] 0xffffffff other info that might help us debug this: 1 lock held by bash/10032: #0: (cgroup_mutex){--..}, at: [] cgroup_lock+0xf/0x20 stack backtrace: Pid: 10032, comm: bash Not tainted 2.6.26-rc7 #25 [] print_circular_bug_tail+0x77/0x90 [] __lock_acquire+0xaf5/0x1040 [] lock_acquire+0x98/0xd0 [] ? get_online_cpus+0x2c/0x40 [] mutex_lock_nested+0xb1/0x300 [] ? get_online_cpus+0x2c/0x40 [] ? get_online_cpus+0x2c/0x40 [] get_online_cpus+0x2c/0x40 [] rebuild_sched_domains+0x7d/0x3a0 [] ? mark_held_locks+0x65/0x80 [] ? kfree+0xb5/0x120 [] ? heap_free+0xa/0x10 [] ? heap_free+0xa/0x10 [] cpuset_common_file_write+0x204/0x440 [] ? started_after+0x0/0x70 [] ? native_sched_clock+0xb5/0x110 [] ? started_after+0x0/0x70 [] ? cpuset_test_cpumask+0x0/0x20 [] ? cpuset_change_cpumask+0x0/0x20 [] cgroup_file_write+0x67/0x130 [] ? cpuset_common_file_write+0x0/0x440 [] ? native_sched_clock+0xb5/0x110 [] vfs_write+0x96/0x130 [] ? cgroup_file_write+0x0/0x130 [] sys_write+0x3d/0x70 [] sysenter_past_esp+0x78/0xd1 =======================