Re: possible recursive locking detected - while running fs operations in loops - 2.6.18-rc2-git5



On Wed, 26 Jul 2006 00:16:42 +0200
"Jesper Juhl" <jesper.juhl@xxxxxxxxx> wrote:

I just got this from the lock validator :

=============================================
[ INFO: possible recursive locking detected ]
---------------------------------------------
rm/2498 is trying to acquire lock:
(&inode->i_mutex){--..}, at: [<c031c3ac>] mutex_lock+0x1c/0x20

but task is already holding lock:
(&inode->i_mutex){--..}, at: [<c031c3ac>] mutex_lock+0x1c/0x20

other info that might help us debug this:
2 locks held by rm/2498:
#0: (&inode->i_mutex/1){--..}, at: [<c017b6f3>] do_rmdir+0x73/0xe0
#1: (&inode->i_mutex){--..}, at: [<c031c3ac>] mutex_lock+0x1c/0x20

stack backtrace:
[<c0103faa>] show_trace_log_lvl+0x12a/0x150
[<c0103fe2>] show_trace+0x12/0x20
[<c01040f9>] dump_stack+0x19/0x20
[<c0138a19>] print_deadlock_bug+0xb9/0xd0
[<c0138a9b>] check_deadlock+0x6b/0x80
[<c013a344>] __lock_acquire+0x354/0x990
[<c013b0a5>] lock_acquire+0x75/0xa0
[<c031c430>] __mutex_lock_slowpath+0x70/0x2a0
[<c031c3ac>] mutex_lock+0x1c/0x20
[<c01ac8b3>] reiserfs_delete_inode+0x63/0xd0
[<c01854e1>] generic_delete_inode+0x61/0xe0
[<c01856af>] generic_drop_inode+0xf/0x20
[<c0185716>] iput+0x56/0x80
[<c01826de>] dentry_iput+0x5e/0xc0
[<c01827e8>] dput+0xa8/0x170
[<c0182c0b>] prune_one_dentry+0x6b/0x80
[<c0182d7b>] prune_dcache+0x15b/0x170
[<c0182ff0>] shrink_dcache_parent+0x10/0x20
[<c017b55a>] dentry_unhash+0x5a/0xc0
[<c017b61f>] vfs_rmdir+0x5f/0xc0
[<c017b74d>] do_rmdir+0xcd/0xe0
[<c017b770>] sys_rmdir+0x10/0x20
[<c010304b>] syscall_call+0x7/0xb
[<b7e79d7d>] 0xb7e79d7d

The VFS takes the directory i_mutex and reiserfs_delete_inode() takes the
to-be-deleted file's i_mutex.

That's notabug and lockdep will need to be taught about it.

That being said, the reiserfs locking appears to be unneeded - this inode
is going down and nobody else can look it up, so what is to be locked
against?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • 5.4-RELEASE lockups on amd64 SMP
    ... lock order reversal ... KDB: enter: withness_ckeckorder ... Not sure where to go from here except to watch the system and wait for more kernel debug output. ...
    (freebsd-stable)
  • RE: 5.4-RELEASE lockups on amd64 SMP
    ... lock order reversal ... Not sure where to go from here except to watch the system and wait for more kernel debug output. ... Debug help - 5.3 lockups on amd64 SMP ...
    (freebsd-stable)
  • Re: realtime-preempt patch-2.6.18-rt7 oops
    ... Turned on some kernel debug switches, notably CONFIG_DEBUG_PREEMPT, ... possible irq lock inversion dependency detected] ... initial-use at: ... rncbc aka Rui Nuno Capela ...
    (Linux-Kernel)
  • Re: realtime-preempt patch-2.6.18-rt7 oops
    ... Turned on some kernel debug switches, notably CONFIG_DEBUG_PREEMPT, ... possible irq lock inversion dependency detected] ... initial-use at: ... the second lock's dependencies: ...
    (Linux-Kernel)
  • Re: [BUG] 2.6.28-git LOCKDEP: Possible recursive rq->lock
    ... klogd/5062 is trying to acquire lock: ... but task is already holding lock: ... let me trace this and debug further. ...
    (Linux-Kernel)