lkml.org 
[lkml]   [2006]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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@gmail.com> 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-07-26 07:41    [W:0.041 / U:10.716 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site