Re: Possible recursive locking detected with XFS
On Thu, Dec 13, 2007 at 06:29:16PM +0300, Vladislav Bolkhovitin wrote:
> I've just got it while running "dbench 200" over a XFS mounted
> partition. Kernel is 2.6.23. See the attachment.
..
> Dec 13 16:30:45 tst kernel: [ 917.365836]
> =
> Dec 13 16:30:45 tst kernel: [ 917.372856] [ INFO: possible recursive locking
> detected ]
> Dec 13 16:30:45 tst kernel: [ 917.378269] 2.6.23-dbg #17
> Dec 13 16:30:45 tst kernel: [ 917.381435]
> -
> Dec 13 16:30:45 tst kernel: [ 917.386838] dbench/3538 is trying to acquire
> lock:
> Dec 13 16:30:45 tst kernel: [ 917.391687]
> (&(>i_iolock)->mr_lock){}, at: [] xfs_ilock+0x90/0x9c [xfs]
> Dec 13 16:30:45 tst kernel: [ 917.400262]
> Dec 13 16:30:45 tst kernel: [ 917.400264] but task is already holding lock:
> Dec 13 16:30:45 tst kernel: [ 917.406116]
> (&(>i_iolock)->mr_lock){}, at: [] xfs_ilock+0x90/0x9c [xfs]
> Dec 13 16:30:45 tst kernel: [ 917.414503]
> Dec 13 16:30:45 tst kernel: [ 917.414505] other info that might help us
> debug this:
> Dec 13 16:30:45 tst kernel: [ 917.421242] 3 locks held by dbench/3538:
> Dec 13 16:30:45 tst kernel: [ 917.425178] #0: (>i_mutex){--..}, at:
> [<783626a6>] mutex_lock+0x1c/0x1f
> Dec 13 16:30:45 tst kernel: [ 917.432805] #1:
> (&(>i_iolock)->mr_lock){}, at: [] xfs_ilock+0x90/0x9c [xfs]
> Dec 13 16:30:45 tst kernel: [ 917.441696] #2:
> (>s_umount_key#17){}, at: [<78191411>] writeback_inodes+0x88/0xd5
> Dec 13 16:30:45 tst kernel: [ 917.450578]
> Dec 13 16:30:45 tst kernel: [ 917.450582] stack backtrace:
> Dec 13 16:30:45 tst kernel: [ 917.455011] [<78103d59>]
> show_trace_log_lvl+0x1a/0x30
> Dec 13 16:30:45 tst kernel: [ 917.460279] [<7810488d>] show_trace+0x12/0x14
> Dec 13 16:30:45 tst kernel: [ 917.464759] [<781048a5>] dump_stack+0x16/0x18
> Dec 13 16:30:45 tst kernel: [ 917.469262] [<7813f883>]
> __lock_acquire+0xdd1/0x106e
> Dec 13 16:30:45 tst kernel: [ 917.474360] [<7813fb89>]
> lock_acquire+0x69/0x82
> Dec 13 16:30:45 tst kernel: [ 917.479000] [<78136184>]
> down_write_nested+0x40/0x88
> Dec 13 16:30:45 tst kernel: [ 917.484195] [] xfs_ilock+0x90/0x9c
> [xfs]
> Dec 13 16:30:45 tst kernel: [ 917.489180] []
> xfs_inactive+0x329/0x4ed [xfs]
> Dec 13 16:30:45 tst kernel: [ 917.494565] []
> xfs_fs_clear_inode+0x7a/0xbe [xfs]
> Dec 13 16:30:45 tst kernel: [ 917.500415] [<78188a78>]
> clear_inode+0xb2/0x14d
> Dec 13 16:30:45 tst kernel: [ 917.505078] [<78188c0b>]
> generic_delete_inode+0xf8/0x105
> Dec 13 16:30:45 tst kernel: [ 917.510513] [<78188d27>]
> generic_drop_inode+0x10f/0x141
> Dec 13 16:30:45 tst kernel: [ 917.515854] [<78188226>] iput+0x5f/0x66
> Dec 13 16:30:45 tst kernel: [ 917.519836] [<781911ae>]
> sync_sb_inodes+0x1f6/0x25c
> Dec 13 16:30:45 tst kernel: [ 917.525032] [<7819142f>]
> writeback_inodes+0xa6/0xd5
> Dec 13 16:30:45 tst kernel: [ 917.530070] [<7815c9f3>]
> balance_dirty_pages_ratelimited_nr+0xdd/0x204
> Dec 13 16:30:45 tst kernel: [ 917.536716] [<781580e4>]
> generic_file_buffered_write+0x2e2/0x69c
> Dec 13 16:30:45 tst kernel: [ 917.542855] []
> xfs_write+0x619/0xaab [xfs]
> Dec 13 16:30:45 tst kernel: [ 917.547990] []
> xfs_file_aio_write+0x70/0x7c [xfs]
> Dec 13 16:30:45 tst kernel: [ 917.553770] [<78175d65>]
> do_sync_write+0xd0/0x106
> Dec 13 16:30:45 tst kernel: [ 917.558620] [<78176552>] vfs_write+0x8b/0x149
> Dec 13 16:30:45 tst kernel: [ 917.563113] [<78176bc4>] sys_write+0x3d/0x64
> Dec 13 16:30:45 tst kernel: [ 917.567526] [<78102ca2>]
> sysenter_past_esp+0x5f/0x99
> Dec 13 16:30:45 tst kernel: [ 917.572635] ===
Oh, this is the classic "recurse into the filesystem to do something
that requires locks while holding a lock on a different inode" false positive.
Basically, we are holding the iolock on inode A when we call
generic_file_buffered_write() and that does something that takes the
iolock on inode B which triggers the report because we don't normally
nest iolocks. We also see this regularly with memory reclaim being
triggered from within the filesystem.
AFAICT, there is no way we can annotate these cases because they are
completely disconnected - there is no relationship or dependency between
the two inodes and so false positives due to recursion like this seems
to me to be impossible to annotate away cleanly.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
--
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: Possible recursive locking detected with XFS
On Thu, Dec 13, 2007 at 06:29:16PM +0300, Vladislav Bolkhovitin wrote:
I've just got it while running dbench 200 over a XFS mounted
partition. Kernel is 2.6.23. See the attachment.
..
Dec 13 16:30:45 tst kernel: [ 917.365836]
=
Dec 13 16:30:45 tst kernel: [ 917.372856] [ INFO: possible recursive locking
detected ]
Dec 13 16:30:45 tst kernel: [ 917.378269] 2.6.23-dbg #17
Dec 13 16:30:45 tst kernel: [ 917.381435]
-
Dec 13 16:30:45 tst kernel: [ 917.386838] dbench/3538 is trying to acquire
lock:
Dec 13 16:30:45 tst kernel: [ 917.391687]
((ip-i_iolock)-mr_lock){}, at: [f89ad79c] xfs_ilock+0x90/0x9c [xfs]
Dec 13 16:30:45 tst kernel: [ 917.400262]
Dec 13 16:30:45 tst kernel: [ 917.400264] but task is already holding lock:
Dec 13 16:30:45 tst kernel: [ 917.406116]
((ip-i_iolock)-mr_lock){}, at: [f89ad79c] xfs_ilock+0x90/0x9c [xfs]
Dec 13 16:30:45 tst kernel: [ 917.414503]
Dec 13 16:30:45 tst kernel: [ 917.414505] other info that might help us
debug this:
Dec 13 16:30:45 tst kernel: [ 917.421242] 3 locks held by dbench/3538:
Dec 13 16:30:45 tst kernel: [ 917.425178] #0: (inode-i_mutex){--..}, at:
[783626a6] mutex_lock+0x1c/0x1f
Dec 13 16:30:45 tst kernel: [ 917.432805] #1:
((ip-i_iolock)-mr_lock){}, at: [f89ad79c] xfs_ilock+0x90/0x9c [xfs]
Dec 13 16:30:45 tst kernel: [ 917.441696] #2:
(type-s_umount_key#17){}, at: [78191411] writeback_inodes+0x88/0xd5
Dec 13 16:30:45 tst kernel: [ 917.450578]
Dec 13 16:30:45 tst kernel: [ 917.450582] stack backtrace:
Dec 13 16:30:45 tst kernel: [ 917.455011] [78103d59]
show_trace_log_lvl+0x1a/0x30
Dec 13 16:30:45 tst kernel: [ 917.460279] [7810488d] show_trace+0x12/0x14
Dec 13 16:30:45 tst kernel: [ 917.464759] [781048a5] dump_stack+0x16/0x18
Dec 13 16:30:45 tst kernel: [ 917.469262] [7813f883]
__lock_acquire+0xdd1/0x106e
Dec 13 16:30:45 tst kernel: [ 917.474360] [7813fb89]
lock_acquire+0x69/0x82
Dec 13 16:30:45 tst kernel: [ 917.479000] [78136184]
down_write_nested+0x40/0x88
Dec 13 16:30:45 tst kernel: [ 917.484195] [f89ad79c] xfs_ilock+0x90/0x9c
[xfs]
Dec 13 16:30:45 tst kernel: [ 917.489180] [f89d13b7]
xfs_inactive+0x329/0x4ed [xfs]
Dec 13 16:30:45 tst kernel: [ 917.494565] [f89dc052]
xfs_fs_clear_inode+0x7a/0xbe [xfs]
Dec 13 16:30:45 tst kernel: [ 917.500415] [78188a78]
clear_inode+0xb2/0x14d
Dec 13 16:30:45 tst kernel: [ 917.505078] [78188c0b]
generic_delete_inode+0xf8/0x105
Dec 13 16:30:45 tst kernel: [ 917.510513] [78188d27]
generic_drop_inode+0x10f/0x141
Dec 13 16:30:45 tst kernel: [ 917.515854] [78188226] iput+0x5f/0x66
Dec 13 16:30:45 tst kernel: [ 917.519836] [781911ae]
sync_sb_inodes+0x1f6/0x25c
Dec 13 16:30:45 tst kernel: [ 917.525032] [7819142f]
writeback_inodes+0xa6/0xd5
Dec 13 16:30:45 tst kernel: [ 917.530070] [7815c9f3]
balance_dirty_pages_ratelimited_nr+0xdd/0x204
Dec 13 16:30:45 tst kernel: [ 917.536716] [781580e4]
generic_file_buffered_write+0x2e2/0x69c
Dec 13 16:30:45 tst kernel: [ 917.542855] [f89db3fe]
xfs_write+0x619/0xaab [xfs]
Dec 13 16:30:45 tst kernel: [ 917.547990] [f89d776e]
xfs_file_aio_write+0x70/0x7c [xfs]
Dec 13 16:30:45 tst kernel: [ 917.553770] [78175d65]
do_sync_write+0xd0/0x106
Dec 13 16:30:45 tst kernel: [ 917.558620] [78176552] vfs_write+0x8b/0x149
Dec 13 16:30:45 tst kernel: [ 917.563113] [78176bc4] sys_write+0x3d/0x64
Dec 13 16:30:45 tst kernel: [ 917.567526] [78102ca2]
sysenter_past_esp+0x5f/0x99
Dec 13 16:30:45 tst kernel: [ 917.572635] ===
Oh, this is the classic recurse into the filesystem to do something
that requires locks while holding a lock on a different inode false positive.
Basically, we are holding the iolock on inode A when we call
generic_file_buffered_write() and that does something that takes the
iolock on inode B which triggers the report because we don't normally
nest iolocks. We also see this regularly with memory reclaim being
triggered from within the filesystem.
AFAICT, there is no way we can annotate these cases because they are
completely disconnected - there is no relationship or dependency between
the two inodes and so false positives due to recursion like this seems
to me to be impossible to annotate away cleanly.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
--
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/
Possible recursive locking detected with XFS
I've just got it while running "dbench 200" over a XFS mounted partition. Kernel is 2.6.23. See the attachment. Regards, Vlad Dec 13 16:17:20 tst kernel: [0.00] Linux version 2.6.23-dbg ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #17 SMP PREEMPT Thu Oct 25 22:19:38 MSD 2007 Dec 13 16:17:20 tst kernel: [0.00] BIOS-provided physical RAM map: Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: - 0009fc00 (usable) Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: 0009fc00 - 000a (reserved) Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: 000e - 0010 (reserved) Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: 0010 - 7fff (usable) Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: 7fff - 7000 (ACPI data) Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: 7000 - 8000 (ACPI NVS) Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: fec0 - fed0 (reserved) Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: fee0 - fee01000 (reserved) Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: fff8 - 0001 (reserved) Dec 13 16:17:20 tst kernel: [0.00] 2047MB LOWMEM available. Dec 13 16:17:20 tst kernel: [0.00] found SMP MP-table at 000ff780 Dec 13 16:17:20 tst kernel: [0.00] Zone PFN ranges: Dec 13 16:17:20 tst kernel: [0.00] DMA 0 -> 4096 Dec 13 16:17:20 tst kernel: [0.00] Normal 4096 -> 524272 Dec 13 16:17:20 tst kernel: [0.00] Movable zone start PFN for each node Dec 13 16:17:20 tst kernel: [0.00] early_node_map[1] active PFN ranges Dec 13 16:17:20 tst kernel: [0.00] 0:0 -> 524272 Dec 13 16:17:20 tst kernel: [0.00] DMI 2.3 present. Dec 13 16:17:20 tst kernel: [0.00] ACPI: RSDP 000F5070, 0014 (r0 ACPIAM) Dec 13 16:17:20 tst kernel: [0.00] ACPI: RSDT 7FFF, 0030 (r1 A M I OEMRSDT 9000318 MSFT 97) Dec 13 16:17:20 tst kernel: [0.00] ACPI: FACP 7FFF0200, 0081 (r2 A M I OEMFACP 9000318 MSFT 97) Dec 13 16:17:20 tst kernel: [0.00] ACPI: DSDT 7FFF0420, 2CB5 (r1 0ABBP 0ABBP0044 INTL 2002026) Dec 13 16:17:20 tst kernel: [0.00] ACPI: FACS 7000, 0040 Dec 13 16:17:20 tst kernel: [0.00] ACPI: APIC 7FFF0390, 0084 (r1 A M I OEMAPIC 9000318 MSFT 97) Dec 13 16:17:20 tst kernel: [0.00] ACPI: OEMB 7040, 0040 (r1 A M I AMI_OEM 9000318 MSFT 97) Dec 13 16:17:20 tst kernel: [0.00] ACPI: PM-Timer IO Port: 0x408 Dec 13 16:17:20 tst kernel: [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Dec 13 16:17:20 tst kernel: [0.00] Processor #0 15:2 APIC version 20 Dec 13 16:17:20 tst kernel: [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Dec 13 16:17:20 tst kernel: [0.00] Processor #1 15:2 APIC version 20 Dec 13 16:17:20 tst kernel: [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) Dec 13 16:17:20 tst kernel: [0.00] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) Dec 13 16:17:20 tst kernel: [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) Dec 13 16:17:20 tst kernel: [0.00] IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 Dec 13 16:17:20 tst kernel: [0.00] ACPI: IOAPIC (id[0x03] address[0xfec8] gsi_base[24]) Dec 13 16:17:20 tst kernel: [0.00] IOAPIC[1]: apic_id 3, version 32, address 0xfec8, GSI 24-47 Dec 13 16:17:20 tst kernel: [0.00] ACPI: IOAPIC (id[0x04] address[0xfec80400] gsi_base[48]) Dec 13 16:17:20 tst kernel: [0.00] IOAPIC[2]: apic_id 4, version 32, address 0xfec80400, GSI 48-71 Dec 13 16:17:20 tst kernel: [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) Dec 13 16:17:20 tst kernel: [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Dec 13 16:17:20 tst kernel: [0.00] Enabling APIC mode: Flat. Using 3 I/O APICs Dec 13 16:17:20 tst kernel: [0.00] Using ACPI (MADT) for SMP configuration information Dec 13 16:17:20 tst kernel: [0.00] Allocating PCI resources starting at 8800 (gap: 8000:7ec0) Dec 13 16:17:20 tst kernel: [0.00] Built 1 zonelists in Zone order. Total pages: 516081 Dec 13 16:17:20 tst kernel: [0.00] Kernel command line: auto BOOT_IMAGE=2.6.23d ro root=301 nmi_watchdog=1 resume=/dev/hdc1 console=ttyS0,115200n8 Dec 13 16:17:20 tst kernel: [0.00] Enabling fast FPU save and restore... done. Dec 13 16:17:20 tst kernel: [0.00] Enabling unmasked SIMD FPU exception support... done. Dec 13 16:17:20 tst kernel: [0.00] Initializing CPU#0 Dec 13 16:17:20 tst kernel: [0.00] CPU 0 irqstacks, hard=78516000
Possible recursive locking detected with XFS
I've just got it while running dbench 200 over a XFS mounted partition. Kernel is 2.6.23. See the attachment. Regards, Vlad Dec 13 16:17:20 tst kernel: [0.00] Linux version 2.6.23-dbg ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #17 SMP PREEMPT Thu Oct 25 22:19:38 MSD 2007 Dec 13 16:17:20 tst kernel: [0.00] BIOS-provided physical RAM map: Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: - 0009fc00 (usable) Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: 0009fc00 - 000a (reserved) Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: 000e - 0010 (reserved) Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: 0010 - 7fff (usable) Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: 7fff - 7000 (ACPI data) Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: 7000 - 8000 (ACPI NVS) Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: fec0 - fed0 (reserved) Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: fee0 - fee01000 (reserved) Dec 13 16:17:20 tst kernel: [0.00] BIOS-e820: fff8 - 0001 (reserved) Dec 13 16:17:20 tst kernel: [0.00] 2047MB LOWMEM available. Dec 13 16:17:20 tst kernel: [0.00] found SMP MP-table at 000ff780 Dec 13 16:17:20 tst kernel: [0.00] Zone PFN ranges: Dec 13 16:17:20 tst kernel: [0.00] DMA 0 - 4096 Dec 13 16:17:20 tst kernel: [0.00] Normal 4096 - 524272 Dec 13 16:17:20 tst kernel: [0.00] Movable zone start PFN for each node Dec 13 16:17:20 tst kernel: [0.00] early_node_map[1] active PFN ranges Dec 13 16:17:20 tst kernel: [0.00] 0:0 - 524272 Dec 13 16:17:20 tst kernel: [0.00] DMI 2.3 present. Dec 13 16:17:20 tst kernel: [0.00] ACPI: RSDP 000F5070, 0014 (r0 ACPIAM) Dec 13 16:17:20 tst kernel: [0.00] ACPI: RSDT 7FFF, 0030 (r1 A M I OEMRSDT 9000318 MSFT 97) Dec 13 16:17:20 tst kernel: [0.00] ACPI: FACP 7FFF0200, 0081 (r2 A M I OEMFACP 9000318 MSFT 97) Dec 13 16:17:20 tst kernel: [0.00] ACPI: DSDT 7FFF0420, 2CB5 (r1 0ABBP 0ABBP0044 INTL 2002026) Dec 13 16:17:20 tst kernel: [0.00] ACPI: FACS 7000, 0040 Dec 13 16:17:20 tst kernel: [0.00] ACPI: APIC 7FFF0390, 0084 (r1 A M I OEMAPIC 9000318 MSFT 97) Dec 13 16:17:20 tst kernel: [0.00] ACPI: OEMB 7040, 0040 (r1 A M I AMI_OEM 9000318 MSFT 97) Dec 13 16:17:20 tst kernel: [0.00] ACPI: PM-Timer IO Port: 0x408 Dec 13 16:17:20 tst kernel: [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Dec 13 16:17:20 tst kernel: [0.00] Processor #0 15:2 APIC version 20 Dec 13 16:17:20 tst kernel: [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Dec 13 16:17:20 tst kernel: [0.00] Processor #1 15:2 APIC version 20 Dec 13 16:17:20 tst kernel: [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) Dec 13 16:17:20 tst kernel: [0.00] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) Dec 13 16:17:20 tst kernel: [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) Dec 13 16:17:20 tst kernel: [0.00] IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 Dec 13 16:17:20 tst kernel: [0.00] ACPI: IOAPIC (id[0x03] address[0xfec8] gsi_base[24]) Dec 13 16:17:20 tst kernel: [0.00] IOAPIC[1]: apic_id 3, version 32, address 0xfec8, GSI 24-47 Dec 13 16:17:20 tst kernel: [0.00] ACPI: IOAPIC (id[0x04] address[0xfec80400] gsi_base[48]) Dec 13 16:17:20 tst kernel: [0.00] IOAPIC[2]: apic_id 4, version 32, address 0xfec80400, GSI 48-71 Dec 13 16:17:20 tst kernel: [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) Dec 13 16:17:20 tst kernel: [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Dec 13 16:17:20 tst kernel: [0.00] Enabling APIC mode: Flat. Using 3 I/O APICs Dec 13 16:17:20 tst kernel: [0.00] Using ACPI (MADT) for SMP configuration information Dec 13 16:17:20 tst kernel: [0.00] Allocating PCI resources starting at 8800 (gap: 8000:7ec0) Dec 13 16:17:20 tst kernel: [0.00] Built 1 zonelists in Zone order. Total pages: 516081 Dec 13 16:17:20 tst kernel: [0.00] Kernel command line: auto BOOT_IMAGE=2.6.23d ro root=301 nmi_watchdog=1 resume=/dev/hdc1 console=ttyS0,115200n8 Dec 13 16:17:20 tst kernel: [0.00] Enabling fast FPU save and restore... done. Dec 13 16:17:20 tst kernel: [0.00] Enabling unmasked SIMD FPU exception support... done. Dec 13 16:17:20 tst kernel: [0.00] Initializing CPU#0 Dec 13 16:17:20 tst kernel: [0.00] CPU 0 irqstacks, hard=78516000
Re: 2.6.20.3 - possible recursive locking detected - in XFS
Eric Sandeen schrieb: > Jesper Juhl wrote: >> On 26/04/07, David Chinner <[EMAIL PROTECTED]> wrote: > >>> Known false positive - XFS doesn't have the annotations needed for >>> this yet; we've got a patch that will probably make it's way into 6.5.22 >>> that >>> should fix most of these issues. > > wow... 6.5.22 do we really have to wait that long? :) Why wait? If i remember right ( it's about 3 years ago that it had to do with it ), its a quite old patch-version of mother ... IRIX :-) It's fun to see that your can't hide your roots Dave :-) ... so now that .21 ( of the Linux 2.6 series ) i wonder, will there be anybody remembering IRIX 6.5.22 when the Linux kernel reaches to that version number? Hey Google, suck this message in and help us remember this question ! Cheers to all friends of Linux und IRIX Klaus P.S.: Guess i will have to boot my old Indy at home, arrrggghhh, clock-chip battery will be empty again ... 'll have to reset the MAC ... must recover the lost root password ... oh Lord ( no, not you Steve ... ) -- Mit freundlichen Grüssen / best regards Klaus Strebel, Dipl.-Inform. (FH), mailto:[EMAIL PROTECTED] /"\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \ - 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: 2.6.20.3 - possible recursive locking detected - in XFS
Eric Sandeen schrieb: Jesper Juhl wrote: On 26/04/07, David Chinner [EMAIL PROTECTED] wrote: Known false positive - XFS doesn't have the annotations needed for this yet; we've got a patch that will probably make it's way into 6.5.22 that should fix most of these issues. wow... 6.5.22 do we really have to wait that long? :) Why wait? If i remember right ( it's about 3 years ago that it had to do with it ), its a quite old patch-version of mother ... IRIX :-) It's fun to see that your can't hide your roots Dave :-) ... so now that .21 ( of the Linux 2.6 series ) i wonder, will there be anybody remembering IRIX 6.5.22 when the Linux kernel reaches to that version number? Hey Google, suck this message in and help us remember this question ! Cheers to all friends of Linux und IRIX Klaus P.S.: Guess i will have to boot my old Indy at home, arrrggghhh, clock-chip battery will be empty again ... 'll have to reset the MAC ... must recover the lost root password ... oh Lord ( no, not you Steve ... ) -- Mit freundlichen Grüssen / best regards Klaus Strebel, Dipl.-Inform. (FH), mailto:[EMAIL PROTECTED] /\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \ - 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: 2.6.20.3 - possible recursive locking detected - in XFS
Jesper Juhl wrote: > On 26/04/07, David Chinner <[EMAIL PROTECTED]> wrote: >> Known false positive - XFS doesn't have the annotations needed for >> this yet; we've got a patch that will probably make it's way into 6.5.22 that >> should fix most of these issues. wow... 6.5.22 do we really have to wait that long? :) -Eric - 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: 2.6.20.3 - possible recursive locking detected - in XFS
On 26/04/07, David Chinner <[EMAIL PROTECTED]> wrote:
On Wed, Apr 25, 2007 at 11:16:57AM +0200, Jesper Juhl wrote:
>
> Hi,
>
> For your information :
>
> Once in a while I see the message below after I've just created a new XFS
filesystem, mount it and then start copying data to it.
.
> =
> [ INFO: possible recursive locking detected ]
> 2.6.20.3generic #1
> -
> xfs_fsr/6117 is trying to acquire lock:
> (&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xa0 [xfs]
>
> but task is already holding lock:
> (&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xa0 [xfs]
Known false positive - XFS doesn't have the annotations needed for
this yet; we've got a patch that will probably make it's way into 6.5.22 that
should fix most of these issues.
Ok. Thanks for the feedback.
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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: 2.6.20.3 - possible recursive locking detected - in XFS
On 26/04/07, David Chinner [EMAIL PROTECTED] wrote:
On Wed, Apr 25, 2007 at 11:16:57AM +0200, Jesper Juhl wrote:
Hi,
For your information :
Once in a while I see the message below after I've just created a new XFS
filesystem, mount it and then start copying data to it.
.
=
[ INFO: possible recursive locking detected ]
2.6.20.3generic #1
-
xfs_fsr/6117 is trying to acquire lock:
((ip-i_lock)-mr_lock){}, at: [f929422d] xfs_ilock+0x7d/0xa0 [xfs]
but task is already holding lock:
((ip-i_lock)-mr_lock){}, at: [f929422d] xfs_ilock+0x7d/0xa0 [xfs]
Known false positive - XFS doesn't have the annotations needed for
this yet; we've got a patch that will probably make it's way into 6.5.22 that
should fix most of these issues.
Ok. Thanks for the feedback.
--
Jesper Juhl [EMAIL PROTECTED]
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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: 2.6.20.3 - possible recursive locking detected - in XFS
Jesper Juhl wrote: On 26/04/07, David Chinner [EMAIL PROTECTED] wrote: Known false positive - XFS doesn't have the annotations needed for this yet; we've got a patch that will probably make it's way into 6.5.22 that should fix most of these issues. wow... 6.5.22 do we really have to wait that long? :) -Eric - 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: 2.6.20.3 - possible recursive locking detected - in XFS
On Wed, Apr 25, 2007 at 11:16:57AM +0200, Jesper Juhl wrote:
>
> Hi,
>
> For your information :
>
> Once in a while I see the message below after I've just created a new XFS
> filesystem, mount it and then start copying data to it.
.
> =
> [ INFO: possible recursive locking detected ]
> 2.6.20.3generic #1
> -
> xfs_fsr/6117 is trying to acquire lock:
> (&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xa0 [xfs]
>
> but task is already holding lock:
> (&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xa0 [xfs]
Known false positive - XFS doesn't have the annotations needed for
this yet; we've got a patch that will probably make it's way into 6.5.22 that
should fix most of these issues.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
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/
2.6.20.3 - possible recursive locking detected - in XFS
Hi,
For your information :
Once in a while I see the message below after I've just created a new XFS
filesystem, mount it and then start copying data to it.
It doesn't happen every time - if I should try to make a guess at the frequency
I'd say about 1 in 30.
What I do is this.
1. boot the server (an IBM x336) via the network
2. log in via ssh
3. load scsi modules
4. create raid1 of two disks
5. fdisk /dev/sda and create partitions
6. mkfs.xfs /dev/sda
7. mount -t xfs /dev/sda /mnt/mountpoint
8. ssh -x [EMAIL PROTECTED] "tar --create --gzip --one-file-system --file - /
2>/dev/null" | tar --extract --gzip --preserve-permissions --numeric-owner
--directory /mnt/mountpoint --file -
since I do the above via a remote ssh session to the net-booted server, I don't
usually notice
kernel output to the console. But recently I've started looking via dmesg in a
second ssh session and
I can say for sure that most of the time there's no problem, but when there is,
it is the same
"recursive locking" dump I get.
If more info is needed, just let me know.
...
Ending clean XFS mount for filesystem: sda4
=
[ INFO: possible recursive locking detected ]
2.6.20.3generic #1
-
xfs_fsr/6117 is trying to acquire lock:
(&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xa0 [xfs]
but task is already holding lock:
(&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xa0 [xfs]
other info that might help us debug this:
2 locks held by xfs_fsr/6117:
#0: (>i_mutex/1){--..}, at: [] lookup_create+0x25/0x90
#1: (&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xa0
[xfs]
stack backtrace:
[] show_trace_log_lvl+0x1a/0x30
[] show_trace+0x12/0x20
[] dump_stack+0x16/0x20
[] __lock_acquire+0xb01/0xdf0
[] lock_acquire+0x70/0x90
[] down_write+0x3b/0x60
[] xfs_ilock+0x7d/0xa0 [xfs]
[] xfs_iget+0x467/0x7b0 [xfs]
[] xfs_trans_iget+0x108/0x180 [xfs]
[] xfs_ialloc+0xab/0x520 [xfs]
[] xfs_dir_ialloc+0x6c/0x2b0 [xfs]
[] xfs_mkdir+0x399/0x650 [xfs]
[] xfs_vn_mknod+0x119/0x2d0 [xfs]
[] xfs_vn_mkdir+0x18/0x20 [xfs]
[] vfs_mkdir+0x98/0xe0
[] sys_mkdirat+0x8e/0xd0
[] sys_mkdir+0x20/0x30
[] sysenter_past_esp+0x5f/0x99
===
...
--
Jesper Juhl <[EMAIL PROTECTED]>
-
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/
2.6.20.3 - possible recursive locking detected - in XFS
Hi,
For your information :
Once in a while I see the message below after I've just created a new XFS
filesystem, mount it and then start copying data to it.
It doesn't happen every time - if I should try to make a guess at the frequency
I'd say about 1 in 30.
What I do is this.
1. boot the server (an IBM x336) via the network
2. log in via ssh
3. load scsi modules
4. create raid1 of two disks
5. fdisk /dev/sda and create partitions
6. mkfs.xfs /dev/sdasome_partition
7. mount -t xfs /dev/sdasome_partition /mnt/mountpoint
8. ssh -x [EMAIL PROTECTED] tar --create --gzip --one-file-system --file - /
2/dev/null | tar --extract --gzip --preserve-permissions --numeric-owner
--directory /mnt/mountpoint --file -
since I do the above via a remote ssh session to the net-booted server, I don't
usually notice
kernel output to the console. But recently I've started looking via dmesg in a
second ssh session and
I can say for sure that most of the time there's no problem, but when there is,
it is the same
recursive locking dump I get.
If more info is needed, just let me know.
...
Ending clean XFS mount for filesystem: sda4
=
[ INFO: possible recursive locking detected ]
2.6.20.3generic #1
-
xfs_fsr/6117 is trying to acquire lock:
((ip-i_lock)-mr_lock){}, at: [f929422d] xfs_ilock+0x7d/0xa0 [xfs]
but task is already holding lock:
((ip-i_lock)-mr_lock){}, at: [f929422d] xfs_ilock+0x7d/0xa0 [xfs]
other info that might help us debug this:
2 locks held by xfs_fsr/6117:
#0: (inode-i_mutex/1){--..}, at: [c016d8b5] lookup_create+0x25/0x90
#1: ((ip-i_lock)-mr_lock){}, at: [f929422d] xfs_ilock+0x7d/0xa0
[xfs]
stack backtrace:
[c010404a] show_trace_log_lvl+0x1a/0x30
[c0104732] show_trace+0x12/0x20
[c01047e6] dump_stack+0x16/0x20
[c0139311] __lock_acquire+0xb01/0xdf0
[c0139670] lock_acquire+0x70/0x90
[c0133f8b] down_write+0x3b/0x60
[f929422d] xfs_ilock+0x7d/0xa0 [xfs]
[f9294e17] xfs_iget+0x467/0x7b0 [xfs]
[f92aeeb8] xfs_trans_iget+0x108/0x180 [xfs]
[f92997db] xfs_ialloc+0xab/0x520 [xfs]
[f92afadc] xfs_dir_ialloc+0x6c/0x2b0 [xfs]
[f92b82b9] xfs_mkdir+0x399/0x650 [xfs]
[f92c0d99] xfs_vn_mknod+0x119/0x2d0 [xfs]
[f92c0f68] xfs_vn_mkdir+0x18/0x20 [xfs]
[c016ceb8] vfs_mkdir+0x98/0xe0
[c016f57e] sys_mkdirat+0x8e/0xd0
[c016f5e0] sys_mkdir+0x20/0x30
[c0102f7e] sysenter_past_esp+0x5f/0x99
===
...
--
Jesper Juhl [EMAIL PROTECTED]
-
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: 2.6.20.3 - possible recursive locking detected - in XFS
On Wed, Apr 25, 2007 at 11:16:57AM +0200, Jesper Juhl wrote:
Hi,
For your information :
Once in a while I see the message below after I've just created a new XFS
filesystem, mount it and then start copying data to it.
.
=
[ INFO: possible recursive locking detected ]
2.6.20.3generic #1
-
xfs_fsr/6117 is trying to acquire lock:
((ip-i_lock)-mr_lock){}, at: [f929422d] xfs_ilock+0x7d/0xa0 [xfs]
but task is already holding lock:
((ip-i_lock)-mr_lock){}, at: [f929422d] xfs_ilock+0x7d/0xa0 [xfs]
Known false positive - XFS doesn't have the annotations needed for
this yet; we've got a patch that will probably make it's way into 6.5.22 that
should fix most of these issues.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
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/
