Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 229520 - Possible recursive locking detected in xfs code
Summary: Possible recursive locking detected in xfs code
Keywords:
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:
: 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)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
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.