Bug 229520 - Possible recursive locking detected in xfs code
Possible recursive locking detected in xfs code
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
All Linux
medium Severity low
: ---
: ---
Assigned To: Eric Sandeen
Brian Brock
http://oss.sgi.com/bugzilla/show_bug....
:
: 228956 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-21 13:14 EST by Orion Poplawski
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-01 10:52:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2007-02-21 13:14:16 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>]
Comment 1 Eric Sandeen 2007-03-01 16:11:32 EST
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 10:09:35 EDT
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-19 23:11:30 EDT
*** Bug 228956 has been marked as a duplicate of this bug. ***
Comment 4 Eric Sandeen 2007-05-01 10:52:41 EDT
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.