Bug 243303 - XFS recursive lock warning when mounting newly created file system
XFS recursive lock warning when mounting newly created file system
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-08 09:48 EDT by Jes Sorensen
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version: F7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-06 15:30:00 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 Jes Sorensen 2007-06-08 09:48:31 EDT
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 10:47:23 EDT
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-10 23:27:38 EDT
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 04:45:15 EDT
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

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