Red Hat Bugzilla – Bug 229520
Possible recursive locking detected in xfs code
Last modified: 2007-11-30 17:11:57 EST
I know xfs isn't really supported, but this is at least for reference. Also filed upstream, see URL. Feb 21 09:44:49 apapane kernel: [ INFO: possible recursive locking detected ] Feb 21 09:44:49 apapane kernel: 2.6.19-1.2288.fc5debug #1 Feb 21 09:44:49 apapane kernel: --------------------------------------------- Feb 21 09:44:49 apapane kernel: mkdir/4813 is trying to acquire lock: Feb 21 09:44:49 apapane kernel: (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff8816086e> ] xfs_ilock+0x4f/0x74 [xfs] Feb 21 09:44:49 apapane kernel: Feb 21 09:44:49 apapane kernel: but task is already holding lock: Feb 21 09:44:49 apapane kernel: (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff8816086e> ] xfs_ilock+0x4f/0x74 [xfs] Feb 21 09:44:49 apapane kernel: Feb 21 09:44:49 apapane kernel: other info that might help us debug this: Feb 21 09:44:49 apapane kernel: 2 locks held by mkdir/4813: Feb 21 09:44:49 apapane kernel: #0: (&inode->i_mutex/1){--..}, at: [<ffffffff80258ca5>] lookup_create+0x23/0x84 Feb 21 09:44:49 apapane kernel: #1: (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff8816 086e>] xfs_ilock+0x4f/0x74 [xfs] Feb 21 09:44:49 apapane kernel: Feb 21 09:44:49 apapane kernel: stack backtrace: Feb 21 09:44:49 apapane kernel: Feb 21 09:44:49 apapane kernel: Call Trace: Feb 21 09:44:49 apapane kernel: [<ffffffff8026d9b9>] show_trace+0x34/0x47 Feb 21 09:44:49 apapane kernel: [<ffffffff8026d9de>] dump_stack+0x12/0x17 Feb 21 09:44:49 apapane kernel: [<ffffffff802a4a8f>] __lock_acquire+0x132/0x9d4 Feb 21 09:44:49 apapane kernel: [<ffffffff802a58b6>] lock_acquire+0x48/0x63 Feb 21 09:44:49 apapane kernel: [<ffffffff802a16f7>] down_write+0x34/0x3d Feb 21 09:44:49 apapane kernel: [<ffffffff8816086e>] :xfs:xfs_ilock+0x4f/0x74 Feb 21 09:44:49 apapane kernel: [<ffffffff881612b9>] :xfs:xfs_iget+0x35c/0x7e3 Feb 21 09:44:49 apapane kernel: [<ffffffff88175f6c>] :xfs:xfs_trans_iget+0xb4/0x128 Feb 21 09:44:49 apapane kernel: [<ffffffff88164f3f>] :xfs:xfs_ialloc+0x9e/0x47d Feb 21 09:44:49 apapane kernel: [<ffffffff88176954>] :xfs:xfs_dir_ialloc+0x84/0x2cc Feb 21 09:44:49 apapane kernel: [<ffffffff8817d8df>] :xfs:xfs_mkdir+0x314/0x672 Feb 21 09:44:49 apapane kernel: [<ffffffff88185659>] :xfs:xfs_vn_mknod+0x1dd/0x3c4 Feb 21 09:44:49 apapane kernel: [<ffffffff802df28d>] vfs_mkdir+0xf7/0x168 Feb 21 09:44:49 apapane kernel: [<ffffffff802df786>] sys_mkdirat+0x97/0xd8 Feb 21 09:44:49 apapane kernel: [<ffffffff8025f11e>] system_call+0x7e/0x83 Feb 21 09:44:49 apapane kernel: [<00000034b3fbd917>] and [ INFO: possible recursive locking detected ] 2.6.19-1.2288.fc5debug #1 --------------------------------------------- tcsh/4957 is trying to acquire lock: (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff8816086e>] xfs_ilock+0x4f/0x74 [xfs] but task is already holding lock: (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff8816086e>] xfs_ilock+0x4f/0x74 [xfs] other info that might help us debug this: 2 locks held by tcsh/4957: #0: (&inode->i_mutex){--..}, at: [<ffffffff8021bd97>] open_namei+0xec/0x698 #1: (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff8816086e>] xfs_ilock+0x4f/0x74 [xfs] stack backtrace: Call Trace: [<ffffffff8026d9b9>] show_trace+0x34/0x47 [<ffffffff8026d9de>] dump_stack+0x12/0x17 [<ffffffff802a4a8f>] __lock_acquire+0x132/0x9d4 [<ffffffff802a58b6>] lock_acquire+0x48/0x63 [<ffffffff802a16f7>] down_write+0x34/0x3d [<ffffffff8816086e>] :xfs:xfs_ilock+0x4f/0x74 [<ffffffff881612b9>] :xfs:xfs_iget+0x35c/0x7e3 [<ffffffff88175f6c>] :xfs:xfs_trans_iget+0xb4/0x128 [<ffffffff88164f3f>] :xfs:xfs_ialloc+0x9e/0x47d [<ffffffff88176954>] :xfs:xfs_dir_ialloc+0x84/0x2cc [<ffffffff8817ca5d>] :xfs:xfs_create+0x321/0x634 [<ffffffff88185633>] :xfs:xfs_vn_mknod+0x1b7/0x3c4 [<ffffffff8023c2cc>] vfs_create+0x101/0x174 [<ffffffff8021be47>] open_namei+0x19c/0x698 [<ffffffff80228fb2>] do_filp_open+0x1c/0x38 [<ffffffff8021a9d4>] do_sys_open+0x44/0xbe [<ffffffff8025f11e>] system_call+0x7e/0x83 [<00000034b3fbdb02>]
I think these are false assertions, IIRC xfs needs to teach lockdep a bit about how it expects to work... I'll check w/ the sgi guys, I think they were working on this. -Eric
Still nothing upstream for this but it's a low priority, it is a false trip of the lockdep code.
*** Bug 228956 has been marked as a duplicate of this bug. ***
UPSTREAM may not be quite right, but its the closest resolution I can find. :) The sgi guys have recently committed a fix for this, and it should show up in 2.6.22, and make it into FC from there. http://oss.sgi.com/archives/xfs/2007-04/msg00177.html -Eric