possible recursive locking detected

possible recursive locking detected

[Bernd Schubert]

with 2.6.20 and almost all debugging options I get this:

[  293.840172] =============================================
[  293.847880] [ INFO: possible recursive locking detected ]
[  293.853862] 2.6.20.3-debug #11
[  293.857288] ---------------------------------------------
[  293.863243] dd/6202 is trying to acquire lock:
[  293.868192]  (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff881693a6>] xfs_ilock+0x56/0x7a [xfs]
[  293.878200]
[  293.878201] but task is already holding lock:
[  293.884788]  (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff881693a6>] xfs_ilock+0x56/0x7a [xfs]
[  293.894802]
[  293.894803] other info that might help us debug this:
[  293.902116] 2 locks held by dd/6202:
[  293.906114]  #0:  (&inode->i_mutex){--..}, at: [<ffffffff804adbbd>] mutex_lock+0x23/0x27
[  293.915438]  #1:  (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff881693a6>] xfs_ilock+0x56/0x7a [xfs]
[  293.925977]
[  293.925978] stack backtrace:
[  293.930948]
[  293.930949] Call Trace:
[  293.935457]  [<ffffffff8024325a>] __lock_acquire+0x44d/0xc60
[  293.941707]  [<ffffffff80242699>] mark_held_locks+0x5a/0x71
[  293.956483]  [<ffffffff881693a6>] :xfs:xfs_ilock+0x56/0x7a
[  293.962537]  [<ffffffff80243e94>] lock_acquire+0x7c/0xa0
[  293.968447]  [<ffffffff881693a6>] :xfs:xfs_ilock+0x56/0x7a
[  293.974510]  [<ffffffff8023f6cb>] down_write+0x33/0x3f
[  293.980236]  [<ffffffff881693a6>] :xfs:xfs_ilock+0x56/0x7a
[  293.986315]  [<ffffffff88169895>] :xfs:xfs_iget+0x43c/0x7a8
[  293.992509]  [<ffffffff8817f4ad>] :xfs:xfs_trans_iget+0xa9/0x115
[  293.999177]  [<ffffffff8816aa74>] :xfs:xfs_ialloc+0x91/0x453
[  294.005475]  [<ffffffff8817fd6a>] :xfs:xfs_dir_ialloc+0x74/0x286
[  294.012145]  [<ffffffff88184b4b>] :xfs:xfs_create+0x347/0x626
[  294.018532]  [<ffffffff8818ee57>] :xfs:xfs_vn_mknod+0x1e2/0x432
[  294.025077]  [<ffffffff8023f733>] up_read+0x24/0x28
[  294.030501]  [<ffffffff88169f69>] :xfs:xfs_iunlock+0x74/0x79
[  294.036788]  [<ffffffff881837d1>] :xfs:xfs_access+0x43/0x4e
[  294.042943]  [<ffffffff80243a15>] __lock_acquire+0xc08/0xc60
[  294.049200]  [<ffffffff804afa5b>] _spin_unlock_irqrestore+0x3f/0x47
[  294.056083]  [<ffffffff80242699>] mark_held_locks+0x5a/0x71
[  294.062239]  [<ffffffff804afa5b>] _spin_unlock_irqrestore+0x3f/0x47
[  294.069138]  [<ffffffff802428a5>] trace_hardirqs_on+0x129/0x154
[  294.075690]  [<ffffffff881837d1>] :xfs:xfs_access+0x43/0x4e
[  294.081883]  [<ffffffff8818f0b2>] :xfs:xfs_vn_create+0xb/0xd
[  294.088139]  [<ffffffff80281eeb>] vfs_create+0xb7/0xfb
[  294.093826]  [<ffffffff80282342>] open_namei+0x1d1/0x6d3
[  294.099717]  [<ffffffff80243a15>] __lock_acquire+0xc08/0xc60
[  294.105970]  [<ffffffff80278796>] do_filp_open+0x5b/0x7e
[  294.111851]  [<ffffffff80278b2a>] do_sys_open+0x4d/0xd4
[  294.117636]  [<ffffffff80278bcc>] sys_open+0x1b/0x1d
[  294.123128]  [<ffffffff8020965e>] system_call+0x7e/0x83
[  294.128913]

Thanks,
Bernd

Re: possible recursive locking detected

[Eric Sandeen]

Bernd Schubert wrote:
> with 2.6.20 and almost all debugging options I get this:
> 
> [  293.840172] =============================================
> [  293.847880] [ INFO: possible recursive locking detected ]
> [  293.853862] 2.6.20.3-debug #11
> [  293.857288] ---------------------------------------------

Many of these have been addressed with this patch:

http://oss.sgi.com/archives/xfs/2007-04/msg00177.html

-Eric

possible recursive locking detected

[Christian Kujau]

Hi,

when I enabled a few more debug-options in the kernel (vanilla 
2.6.21-rc5), I came across:

[ INFO: possible recursive locking detected ]
2.6.21-rc5 #2
---------------------------------------------
rm/32198 is trying to acquire lock:
xfs_ilock+0x71/0xa0

but task is already holding lock:
xfs_ilock+0x71/0xa0

other info that might help us debug this:
3 locks held by rm/32198:
do_unlinkat+0x96/0x160
vfs_unlink+0x75/0xe0
xfs_ilock+0x71/0xa0

stack backtrace:
__lock_acquire+0xa99/0x1010
lock_acquire+0x57/0x70
xfs_ilock+0x71/0xa0
down_write+0x38/0x50
xfs_ilock+0x71/0xa0
xfs_ilock+0x71/0xa0
xfs_lock_dir_and_entry+0xf6/0x100
xfs_remove+0x197/0x4e0
d_instantiate+0x19/0x40
d_rehash+0x20/0x50
vfs_unlink+0x75/0xe0
xfs_vn_unlink+0x23/0x60
__mutex_lock_slowpath+0x13f/0x280
mark_held_locks+0x6b/0x90
__mutex_lock_slowpath+0x13f/0x280
__mutex_lock_slowpath+0x13f/0x280
trace_hardirqs_on+0xb9/0x160
vfs_unlink+0x75/0xe0
__mutex_lock_slowpath+0x132/0x280
vfs_unlink+0x75/0xe0
permission+0x91/0xf0
vfs_unlink+0x89/0xe0
do_unlinkat+0xd2/0x160
sysenter_past_esp+0x8d/0x99
trace_hardirqs_on+0xb9/0x160
sysenter_past_esp+0x5d/0x99
  =======================


Is this something I have to worry about?
Please see http://nerdbynature.de/bits/2.6.21-rc5/ for a few more 
details.

Thanks,
Christian.
-- 
BOFH excuse #372:

Forced to support NT servers; sysadmins quit.

Re: possible recursive locking detected

[Christian Kujau]

Hi there,

On Mon, April 2, 2007 19:18, Christian Kujau wrote:
> when I enabled a few more debug-options in the kernel (vanilla
> 2.6.21-rc5), I came across:
>
> [ INFO: possible recursive locking detected ]
> 2.6.21-rc5 #2

The same happened with -rc7, see below. Can anyone comment if this
is/could lead to a problem?


Thanks,
Christian.

Please see http://nerdbynature.de/bits/2.6.21-rc7/ for full details:

[37380.435689] =============================================
[37380.435703] [ INFO: possible recursive locking detected ]
[37380.435707] 2.6.21-rc7 #6
[37380.435710] ---------------------------------------------
[37380.435715] rm/14081 is trying to acquire lock:
[37380.435719]  (&(&ip->i_lock)->mr_lock){----}, at: [<c0246871>]
xfs_ilock+0x71/0xa0
[37380.435734]
[37380.435735] but task is already holding lock:
[37380.435739]  (&(&ip->i_lock)->mr_lock){----}, at: [<c0246871>]
xfs_ilock+0x71/0xa0
[37380.435749]
[37380.435750] other info that might help us debug this:
[37380.435755] 3 locks held by rm/14081:
[37380.435758]  #0:  (&inode->i_mutex/1){--..}, at: [<c0167196>]
do_unlinkat+0x96/0x160
[37380.435770]  #1:  (&inode->i_mutex){--..}, at: [<c0165475>]
vfs_unlink+0x75/0xe0
[37380.435782]  #2:  (&(&ip->i_lock)->mr_lock){----}, at: [<c0246871>]
xfs_ilock+0x71/0xa0
[37380.435792]
[37380.435792] stack backtrace:
[37380.435798]  [<c0134aa9>] __lock_acquire+0xa99/0x1010
[37380.435808]  [<c0135077>] lock_acquire+0x57/0x70
[37380.435814]  [<c0246871>] xfs_ilock+0x71/0xa0
[37380.435820]  [<c012e408>] down_write+0x38/0x50
[37380.435828]  [<c0246871>] xfs_ilock+0x71/0xa0
[37380.435833]  [<c0246871>] xfs_ilock+0x71/0xa0
[37380.435839]  [<c026bc06>] xfs_lock_dir_and_entry+0xf6/0x100
[37380.435847]  [<c026c287>] xfs_remove+0x197/0x4e0
[37380.435853]  [<c016dce9>] d_instantiate+0x19/0x40
[37380.435860]  [<c016db50>] d_rehash+0x20/0x50
[37380.435868]  [<c0165475>] vfs_unlink+0x75/0xe0
[37380.435875]  [<c0273ce3>] xfs_vn_unlink+0x23/0x60
[37380.435882]  [<c03ce55f>] __mutex_lock_slowpath+0x13f/0x280
[37380.435889]  [<c013394b>] mark_held_locks+0x6b/0x90
[37380.435894]  [<c03ce55f>] __mutex_lock_slowpath+0x13f/0x280
[37380.435900]  [<c03ce55f>] __mutex_lock_slowpath+0x13f/0x280
[37380.435906]  [<c0133ad9>] trace_hardirqs_on+0xb9/0x160
[37380.435913]  [<c0165475>] vfs_unlink+0x75/0xe0
[37380.435919]  [<c03ce552>] __mutex_lock_slowpath+0x132/0x280
[37380.435925]  [<c0165475>] vfs_unlink+0x75/0xe0
[37380.435931]  [<c0164a51>] permission+0x91/0xf0
[37380.435938]  [<c0165489>] vfs_unlink+0x89/0xe0
[37380.435945]  [<c01671d2>] do_unlinkat+0xd2/0x160
[37380.435953]  [<c0102938>] restore_nocheck+0x12/0x15
[37380.435959]  [<c0133ad9>] trace_hardirqs_on+0xb9/0x160
[37380.435967]  [<c0102864>] sysenter_past_esp+0x5d/0x99
[37380.435976]  =======================


-- 
BOFH excuse #442:

Trojan horse ran out of hay

Re: possible recursive locking detected

[Eric Sandeen]

Christian Kujau wrote:
> Hi there,
> 
> On Mon, April 2, 2007 19:18, Christian Kujau wrote:
>> when I enabled a few more debug-options in the kernel (vanilla
>> 2.6.21-rc5), I came across:
>>
>> [ INFO: possible recursive locking detected ]
>> 2.6.21-rc5 #2
> 
> The same happened with -rc7, see below. Can anyone comment if this
> is/could lead to a problem?
>

The consensus seems to be that it is cosmetic.

-Eric

Re: possible recursive locking detected

[Christoph Hellwig]

On Mon, Apr 23, 2007 at 02:46:43PM -0500, Eric Sandeen wrote:
> Christian Kujau wrote:
> > Hi there,
> > 
> > On Mon, April 2, 2007 19:18, Christian Kujau wrote:
> >> when I enabled a few more debug-options in the kernel (vanilla
> >> 2.6.21-rc5), I came across:
> >>
> >> [ INFO: possible recursive locking detected ]
> >> 2.6.21-rc5 #2
> > 
> > The same happened with -rc7, see below. Can anyone comment if this
> > is/could lead to a problem?
> >
> 
> The consensus seems to be that it is cosmetic.

It's not really cosmetic.  It means i_lock and i_iolock are beeing
acquired without an order that is detectable by lockdep.  At the very
first it means annotations for lockdep are missing, because acquiring
two per-inode locks at the same time is a basic fact in unix filesystems.
But deeper than that the rules for taking both locks are not very well
defined in XFS.  These rules at least need documentation in form of
lockdep annotations, and possibly some fixes and cleanups around the
more dirty areas like xfs_lock_for_rename() or xfs_lock_dir_and_entry()

Re: possible recursive locking detected

[Christian Kujau]

On Mon, April 23, 2007 22:19, Christoph Hellwig wrote:
> It's not really cosmetic.  It means i_lock and i_iolock are beeing
> acquired without an order that is detectable by lockdep.  At the very first
> it means annotations for lockdep are missing, because acquiring two
> per-inode locks at the same time is a basic fact in unix filesystems.

Thank you both for your comments, now I can sleep better again ;)

Christian.
-- 
BOFH excuse #442:

Trojan horse ran out of hay