Bug 243303

Summary: XFS recursive lock warning when mounting newly created file system
Product: [Fedora] Fedora Reporter: Jes Sorensen <jes>
Component: kernelAssignee: Eric Sandeen <esandeen>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: esandeen
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: F7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-08-06 19:30:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Jes Sorensen 2007-06-08 13:48:31 UTC
Description of problem:

I get this recursive lock warning when mounting a newly created
XFS file system on an x86_64 box with FC7t4.

Version-Release number of selected component (if applicable):

FC7t4

How reproducible:

Seen it once, when unmounting and remounting it, it seemed ok.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:


SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
SGI XFS Quota Management subsystem
XFS mounting filesystem sdb3
Ending clean XFS mount for filesystem: sdb3

=============================================
[ INFO: possible recursive locking detected ]
2.6.21-1.3116.fc7 #1
---------------------------------------------
mkdir/4781 is trying to acquire lock:
 (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff883bc303>] xfs_ilock+0x58/0x7b [xfs]

but task is already holding lock:
 (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff883bc303>] xfs_ilock+0x58/0x7b [xfs]

other info that might help us debug this:
2 locks held by mkdir/4781:
 #0:  (&inode->i_mutex/1){--..}, at: [<ffffffff8025680e>] lookup_create+0x25/0x88
 #1:  (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff883bc303>]
xfs_ilock+0x58/0x7b [xfs]

stack backtrace:

Call Trace:
 [<ffffffff802a2e53>] __lock_acquire+0x151/0xbd1
 [<ffffffff802a3cc9>] lock_acquire+0x4c/0x65
 [<ffffffff883bc303>] :xfs:xfs_ilock+0x58/0x7b
 [<ffffffff8029e969>] down_write+0x3b/0x47
 [<ffffffff883bc303>] :xfs:xfs_ilock+0x58/0x7b
 [<ffffffff883bcd2e>] :xfs:xfs_iget_core+0x2df/0x6a1
 [<ffffffff802639f3>] _spin_unlock+0x26/0x2a
 [<ffffffff883bd198>] :xfs:xfs_iget+0xa8/0x158
 [<ffffffff883d28f4>] :xfs:xfs_trans_iget+0xb5/0x125
 [<ffffffff883c06a5>] :xfs:xfs_ialloc+0x94/0x44b
 [<ffffffff883d3313>] :xfs:xfs_dir_ialloc+0x73/0x2a4
 [<ffffffff8029e971>] down_write+0x43/0x47
 [<ffffffff883d91ab>] :xfs:xfs_mkdir+0x30a/0x612
 [<ffffffff8839841b>] :xfs:xfs_attr_get+0xc3/0xd5
 [<ffffffff883e2e69>] :xfs:xfs_vn_mknod+0x1f8/0x322
 [<ffffffff883e2fa1>] :xfs:xfs_vn_mkdir+0xe/0x10
 [<ffffffff802e260f>] vfs_mkdir+0xdc/0x150
 [<ffffffff802e2b3d>] sys_mkdirat+0xac/0xf6
 [<ffffffff8026cc40>] syscall_trace_enter+0x9a/0x9f
 [<ffffffff802e2b9a>] sys_mkdir+0x13/0x15
 [<ffffffff8025c2b5>] tracesys+0xdc/0xe1

Comment 1 Eric Sandeen 2007-06-08 14:47:23 UTC
Jes, tell the sgi guys about it!  ;-)  Actually there is a patch which
instruments xfs to fix most of these lockdep issues on xfs, I'll have to see
whether it's made it to the fc kernel yet or not.  I'll probably dup this bug to
another similar one.

Comment 2 Dave Jones 2007-07-11 03:27:38 UTC
I think this may be due to us carrying that patch that still applied with fuzz
(test4 definitly would've still had that patch) which led to us having two
attempts to take that lock in the same function.

Jes, can you try the update kernel ?


Comment 3 Jes Sorensen 2007-07-11 08:45:15 UTC
We updated the system to FC7-final some time ago - I can't find any trace
of the XFS message in the syslog since then.

I'm ok that we close this one - I'll reopen it if it reappears.

Cheers,
Jes