Re: lock checking feedback (bug?) 2.6.20(xfs)/i386 during boot
Thanks for the report, Linda. This and other lockdep reports are on our todo/bug list and I've added this one. (Nathan looked at some of these lock related changes I believe and we still have a pending patch of his to go thru) --Tim --On 18 February 2007 1:38:45 PM -0800 Linda Walsh <[EMAIL PROTECTED]> wrote: Turned on lock testing/proving/deadlock detection. Not chasing any particular problem, but looking for things "oddities". Turned on options (under kernel hacking): Locking API boot-time self-tests RT Mutex debugging, deadlock detection Lock debugging: prove locking correctness Multiple reboots show it to be a constant. I had tried the new "Asynchronous SCSI scanning" -- thought that might have been related, but turning it off makes no difference. I'm guessing this "error" has been present before this, but the lock proving algorithms are bringing it to light? So I don't know how serious this is (if it is anything), but at the least, it doesn't look too clean... Maybe that SCSI device sda: write cache: enabled, read cache: enabled, supports DPO and FUA sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 > sd 0:0:0:0: Attached scsi disk sda UDF-fs: No VRS found XFS mounting filesystem sda3 Ending clean XFS mount for filesystem: sda3 VFS: Mounted root (xfs filesystem) readonly. Freeing unused kernel memory: 316k freed = [ INFO: possible recursive locking detected ] 2.6.20 #3 - rm/682 is trying to acquire lock: (&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xb0 but task is already holding lock: (&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xb0 other info that might help us debug this: 3 locks held by rm/682: #0: (>i_mutex/1){--..}, at: [] do_unlinkat+0x96/0x170 #1: (>i_mutex){--..}, at: [] vfs_unlink+0x5a/0xd0 #2: (&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xb0 stack backtrace: [] __lock_acquire+0xaf1/0xdf0 [] lock_acquire+0x57/0x70 [] xfs_ilock+0x7d/0xb0 [] down_write+0x2f/0x50 [] xfs_ilock+0x7d/0xb0 [] xfs_ilock+0x7d/0xb0 [] xfs_lock_dir_and_entry+0xfd/0x100 [] xfs_remove+0x198/0x4e0 [] xfs_access+0x26/0x50 [] xfs_access+0x26/0x50 [] vfs_unlink+0x5a/0xd0 [] xfs_vn_unlink+0x23/0x60 [] __mutex_lock_slowpath+0x152/0x2a0 [] mark_held_locks+0x6b/0x90 [] __mutex_lock_slowpath+0x152/0x2a0 [] __mutex_lock_slowpath+0x152/0x2a0 [] trace_hardirqs_on+0xc7/0x170 [] __mutex_lock_slowpath+0x145/0x2a0 [] vfs_unlink+0x5a/0xd0 [] permission+0x137/0x140 [] vfs_unlink+0x90/0xd0 [] do_unlinkat+0xd3/0x170 [] do_page_fault+0x327/0x630 [] sysenter_past_esp+0x5f/0x99 === XFS mounting filesystem sda1 Ending clean XFS mount for filesystem: sda1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lock checking feedback (bug?) 2.6.20(xfs)/i386 during boot
Thanks for the report, Linda. This and other lockdep reports are on our todo/bug list and I've added this one. (Nathan looked at some of these lock related changes I believe and we still have a pending patch of his to go thru) --Tim --On 18 February 2007 1:38:45 PM -0800 Linda Walsh [EMAIL PROTECTED] wrote: Turned on lock testing/proving/deadlock detection. Not chasing any particular problem, but looking for things oddities. Turned on options (under kernel hacking): Locking API boot-time self-tests RT Mutex debugging, deadlock detection Lock debugging: prove locking correctness Multiple reboots show it to be a constant. I had tried the new Asynchronous SCSI scanning -- thought that might have been related, but turning it off makes no difference. I'm guessing this error has been present before this, but the lock proving algorithms are bringing it to light? So I don't know how serious this is (if it is anything), but at the least, it doesn't look too clean... Maybe that SCSI device sda: write cache: enabled, read cache: enabled, supports DPO and FUA sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sd 0:0:0:0: Attached scsi disk sda UDF-fs: No VRS found XFS mounting filesystem sda3 Ending clean XFS mount for filesystem: sda3 VFS: Mounted root (xfs filesystem) readonly. Freeing unused kernel memory: 316k freed = [ INFO: possible recursive locking detected ] 2.6.20 #3 - rm/682 is trying to acquire lock: ((ip-i_lock)-mr_lock){}, at: [b024068d] xfs_ilock+0x7d/0xb0 but task is already holding lock: ((ip-i_lock)-mr_lock){}, at: [b024068d] xfs_ilock+0x7d/0xb0 other info that might help us debug this: 3 locks held by rm/682: #0: (inode-i_mutex/1){--..}, at: [b016f946] do_unlinkat+0x96/0x170 #1: (inode-i_mutex){--..}, at: [b016db9a] vfs_unlink+0x5a/0xd0 #2: ((ip-i_lock)-mr_lock){}, at: [b024068d] xfs_ilock+0x7d/0xb0 stack backtrace: [b013aaf1] __lock_acquire+0xaf1/0xdf0 [b013ae47] lock_acquire+0x57/0x70 [b024068d] xfs_ilock+0x7d/0xb0 [b0135d7f] down_write+0x2f/0x50 [b024068d] xfs_ilock+0x7d/0xb0 [b024068d] xfs_ilock+0x7d/0xb0 [b025ff2d] xfs_lock_dir_and_entry+0xfd/0x100 [b0263c68] xfs_remove+0x198/0x4e0 [b025fff6] xfs_access+0x26/0x50 [b025fff6] xfs_access+0x26/0x50 [b016db9a] vfs_unlink+0x5a/0xd0 [b026d8f3] xfs_vn_unlink+0x23/0x60 [b0417f72] __mutex_lock_slowpath+0x152/0x2a0 [b01398bb] mark_held_locks+0x6b/0x90 [b0417f72] __mutex_lock_slowpath+0x152/0x2a0 [b0417f72] __mutex_lock_slowpath+0x152/0x2a0 [b0139a67] trace_hardirqs_on+0xc7/0x170 [b0417f65] __mutex_lock_slowpath+0x145/0x2a0 [b016db9a] vfs_unlink+0x5a/0xd0 [b016d077] permission+0x137/0x140 [b016dbd0] vfs_unlink+0x90/0xd0 [b016f983] do_unlinkat+0xd3/0x170 [b0113807] do_page_fault+0x327/0x630 [b0102fda] sysenter_past_esp+0x5f/0x99 === XFS mounting filesystem sda1 Ending clean XFS mount for filesystem: sda1 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
lock checking feedback (bug?) 2.6.20(xfs)/i386 during boot
Turned on lock testing/proving/deadlock detection. Not chasing any particular problem, but looking for things "oddities". Turned on options (under kernel hacking): Locking API boot-time self-tests RT Mutex debugging, deadlock detection Lock debugging: prove locking correctness Multiple reboots show it to be a constant. I had tried the new "Asynchronous SCSI scanning" -- thought that might have been related, but turning it off makes no difference. I'm guessing this "error" has been present before this, but the lock proving algorithms are bringing it to light? So I don't know how serious this is (if it is anything), but at the least, it doesn't look too clean... Maybe that SCSI device sda: write cache: enabled, read cache: enabled, supports DPO and FUA sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 > sd 0:0:0:0: Attached scsi disk sda UDF-fs: No VRS found XFS mounting filesystem sda3 Ending clean XFS mount for filesystem: sda3 VFS: Mounted root (xfs filesystem) readonly. Freeing unused kernel memory: 316k freed = [ INFO: possible recursive locking detected ] 2.6.20 #3 - rm/682 is trying to acquire lock: (&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xb0 but task is already holding lock: (&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xb0 other info that might help us debug this: 3 locks held by rm/682: #0: (>i_mutex/1){--..}, at: [] do_unlinkat+0x96/0x170 #1: (>i_mutex){--..}, at: [] vfs_unlink+0x5a/0xd0 #2: (&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xb0 stack backtrace: [] __lock_acquire+0xaf1/0xdf0 [] lock_acquire+0x57/0x70 [] xfs_ilock+0x7d/0xb0 [] down_write+0x2f/0x50 [] xfs_ilock+0x7d/0xb0 [] xfs_ilock+0x7d/0xb0 [] xfs_lock_dir_and_entry+0xfd/0x100 [] xfs_remove+0x198/0x4e0 [] xfs_access+0x26/0x50 [] xfs_access+0x26/0x50 [] vfs_unlink+0x5a/0xd0 [] xfs_vn_unlink+0x23/0x60 [] __mutex_lock_slowpath+0x152/0x2a0 [] mark_held_locks+0x6b/0x90 [] __mutex_lock_slowpath+0x152/0x2a0 [] __mutex_lock_slowpath+0x152/0x2a0 [] trace_hardirqs_on+0xc7/0x170 [] __mutex_lock_slowpath+0x145/0x2a0 [] vfs_unlink+0x5a/0xd0 [] permission+0x137/0x140 [] vfs_unlink+0x90/0xd0 [] do_unlinkat+0xd3/0x170 [] do_page_fault+0x327/0x630 [] sysenter_past_esp+0x5f/0x99 === XFS mounting filesystem sda1 Ending clean XFS mount for filesystem: sda1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
lock checking feedback (bug?) 2.6.20(xfs)/i386 during boot
Turned on lock testing/proving/deadlock detection. Not chasing any particular problem, but looking for things oddities. Turned on options (under kernel hacking): Locking API boot-time self-tests RT Mutex debugging, deadlock detection Lock debugging: prove locking correctness Multiple reboots show it to be a constant. I had tried the new Asynchronous SCSI scanning -- thought that might have been related, but turning it off makes no difference. I'm guessing this error has been present before this, but the lock proving algorithms are bringing it to light? So I don't know how serious this is (if it is anything), but at the least, it doesn't look too clean... Maybe that SCSI device sda: write cache: enabled, read cache: enabled, supports DPO and FUA sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sd 0:0:0:0: Attached scsi disk sda UDF-fs: No VRS found XFS mounting filesystem sda3 Ending clean XFS mount for filesystem: sda3 VFS: Mounted root (xfs filesystem) readonly. Freeing unused kernel memory: 316k freed = [ INFO: possible recursive locking detected ] 2.6.20 #3 - rm/682 is trying to acquire lock: ((ip-i_lock)-mr_lock){}, at: [b024068d] xfs_ilock+0x7d/0xb0 but task is already holding lock: ((ip-i_lock)-mr_lock){}, at: [b024068d] xfs_ilock+0x7d/0xb0 other info that might help us debug this: 3 locks held by rm/682: #0: (inode-i_mutex/1){--..}, at: [b016f946] do_unlinkat+0x96/0x170 #1: (inode-i_mutex){--..}, at: [b016db9a] vfs_unlink+0x5a/0xd0 #2: ((ip-i_lock)-mr_lock){}, at: [b024068d] xfs_ilock+0x7d/0xb0 stack backtrace: [b013aaf1] __lock_acquire+0xaf1/0xdf0 [b013ae47] lock_acquire+0x57/0x70 [b024068d] xfs_ilock+0x7d/0xb0 [b0135d7f] down_write+0x2f/0x50 [b024068d] xfs_ilock+0x7d/0xb0 [b024068d] xfs_ilock+0x7d/0xb0 [b025ff2d] xfs_lock_dir_and_entry+0xfd/0x100 [b0263c68] xfs_remove+0x198/0x4e0 [b025fff6] xfs_access+0x26/0x50 [b025fff6] xfs_access+0x26/0x50 [b016db9a] vfs_unlink+0x5a/0xd0 [b026d8f3] xfs_vn_unlink+0x23/0x60 [b0417f72] __mutex_lock_slowpath+0x152/0x2a0 [b01398bb] mark_held_locks+0x6b/0x90 [b0417f72] __mutex_lock_slowpath+0x152/0x2a0 [b0417f72] __mutex_lock_slowpath+0x152/0x2a0 [b0139a67] trace_hardirqs_on+0xc7/0x170 [b0417f65] __mutex_lock_slowpath+0x145/0x2a0 [b016db9a] vfs_unlink+0x5a/0xd0 [b016d077] permission+0x137/0x140 [b016dbd0] vfs_unlink+0x90/0xd0 [b016f983] do_unlinkat+0xd3/0x170 [b0113807] do_page_fault+0x327/0x630 [b0102fda] sysenter_past_esp+0x5f/0x99 === XFS mounting filesystem sda1 Ending clean XFS mount for filesystem: sda1 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/