From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755337AbZCNOCl (ORCPT ); Sat, 14 Mar 2009 10:02:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752338AbZCNOCc (ORCPT ); Sat, 14 Mar 2009 10:02:32 -0400 Received: from THUNK.ORG ([69.25.196.29]:51188 "EHLO thunker.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752639AbZCNOCb (ORCPT ); Sat, 14 Mar 2009 10:02:31 -0400 To: linux-kernel@vger.kernel.org Subject: Lockdep problem involving sysfs_mutex in ext4 in linux-next From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Sat, 14 Mar 2009 10:02:27 -0400 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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); 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 the stack trace is: [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 Can anybody tell me what I did wrong? Thanks!! - Ted