Bug 229520 - Possible recursive locking detected in xfs code
Summary: Possible recursive locking detected in xfs code
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 5
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Eric Sandeen
QA Contact: Brian Brock
URL: http://oss.sgi.com/bugzilla/show_bug....
Whiteboard:
Keywords:
: 228956 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-02-21 18:14 UTC by Orion Poplawski
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2007-05-01 14:52:41 UTC


Attachments (Terms of Use)

Description Orion Poplawski 2007-02-21 18:14:16 UTC
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>]

Comment 1 Eric Sandeen 2007-03-01 21:11:32 UTC
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

Comment 2 Eric Sandeen 2007-03-20 14:09:35 UTC
Still nothing upstream for this but it's a low priority, it is a false trip of
the lockdep code.

Comment 3 Eric Sandeen 2007-04-20 03:11:30 UTC
*** Bug 228956 has been marked as a duplicate of this bug. ***

Comment 4 Eric Sandeen 2007-05-01 14:52:41 UTC
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




Note You need to log in before you can comment on or make changes to this bug.