Bug 243303 - XFS recursive lock warning when mounting newly created file system
Summary: XFS recursive lock warning when mounting newly created file system
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Eric Sandeen
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-08 13:48 UTC by Jes Sorensen
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Fixed In Version: F7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-06 19:30:00 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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):


How reproducible:

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

Steps to Reproduce:
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.


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