From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756107AbZCNXFa (ORCPT ); Sat, 14 Mar 2009 19:05:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754837AbZCNXFR (ORCPT ); Sat, 14 Mar 2009 19:05:17 -0400 Received: from casper.infradead.org ([85.118.1.10]:37944 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751079AbZCNXFQ (ORCPT ); Sat, 14 Mar 2009 19:05:16 -0400 Subject: Re: Lockdep problem involving sysfs_mutex in ext4 in linux-next From: Peter Zijlstra To: "Theodore Ts'o" Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Kay Sievers In-Reply-To: References: Content-Type: text/plain Date: Sun, 15 Mar 2009 00:05:08 +0100 Message-Id: <1237071908.8939.788.camel@laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.25.92 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 2009-03-14 at 10:02 -0400, Theodore Ts'o wrote: > I'm occasionally seeing a circular locking dependency in linux-next when > I unmount an ext4 filesystem, apparently involving sysfs_mutex in > sysfs_addrm_start(), and I have no idea what's going on. Some help from > kobject experts would be greatly appreciated. I assume I must be doing > something wrong. I took the basic pattern from btrfs, but I suspect I > may have broken some of the kobject lifetime rules when I adapted what I > needed for ext4. > > It doesn't happen all the time, and it seems to be caused by how I'm > releasing the ext4's sysfs kobject. In ext4_put_super(): > > kobject_put(&sbi->s_kobj); > wait_for_completion(&sbi->s_kobj_unregister); Right that would require sysfs_mutex() while you're holding s_lock. > The circular locking dependency is: > > [32667.071746] ======================================================= > [32667.071751] [ INFO: possible circular locking dependency detected ] > [32667.071755] 2.6.29-rc7-00043-gafbc462 #11 > [32667.071758] ------------------------------------------------------- > [32667.071762] umount/2310 is trying to acquire lock: > [32667.071764] (sysfs_mutex){--..}, at: [] sysfs_addrm_start+0x28/0x9a > [32667.071778] > [32667.071779] but task is already holding lock: > [32667.071782] (&type->s_lock_key#5){--..}, at: [] lock_super+0x26/0x28 And here you snipped the interesting bit here it tells us how you normally have the reverse lock order, namely: sysfs_mutex. s_lock > [32667.072279] [] ? sysfs_addrm_start+0x28/0x9a > [32667.072284] [] __mutex_lock_common+0xdc/0x33a > [32667.072289] [] ? sysfs_addrm_start+0x28/0x9a > [32667.072294] [] mutex_lock_nested+0x33/0x3b > [32667.072300] [] ? sysfs_addrm_start+0x28/0x9a > [32667.072304] [] sysfs_addrm_start+0x28/0x9a > [32667.072309] [] sysfs_remove_dir+0x77/0xab > [32667.072314] [] kobject_del+0xf/0x2c > [32667.072319] [] kobject_release+0x134/0x1cb > [32667.072323] [] ? kobject_release+0x0/0x1cb > [32667.072328] [] kref_put+0x3c/0x4a > [32667.072333] [] kobject_put+0x37/0x3c > [32667.072337] [] ext4_put_super+0xab/0x215 > [32667.072342] [] generic_shutdown_super+0x62/0xe3 > [32667.072346] [] kill_block_super+0x22/0x36 > [32667.072352] [] ? vfs_quota_off+0x0/0x17 > [32667.072357] [] deactivate_super+0x5c/0x6f > [32667.072361] [] mntput_no_expire+0xd4/0x106 > [32667.072366] [] sys_umount+0x2a1/0x2c6 > [32667.072370] [] sys_oldumount+0x12/0x14 > [32667.072375] [] syscall_call+0x7/0xb > [32667.072380] [] ? x86_decode_insn+0x349/0xbc9