Skip to contentSkip to conversation

INFO: possible irq lock inversion dependency detected

qla2xxx In review Srivatsa S. Bhat 5 participants 10 messages Oct 4, 2012 – Oct 9, 2012

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

Hi,

With the mainline kernel (in the merge window) I am seeing the following lockdep splat every time during boot.

Regards,
Srivatsa S. Bhat

------------------------------------>

[    3.940316] SCSI subsystem initialized
[    3.949021] Fusion MPT base driver 3.04.20
[    3.953141] Copyright (c) 1999-2008 LSI Corporation
[    3.955471] Fusion MPT SAS Host driver 3.04.20
[    3.955850] mptbase: ioc0: Initiating bringup
[    4.656179] ioc0: LSISAS1064E B3: Capabilities={Initiator}
[   16.216323] scsi0 : ioc0: LSISAS1064E B3, FwRev=011e0000h, Ports=1, MaxQ=277, IRQ=28
[   16.248414] mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 1, phy 0, sas_addr 0x5000c5001d7e18c9
[   16.259708] scsi 0:0:0:0: Direct-Access     IBM-ESXS ST9146803SS      B536 PQ: 0 ANSI: 5
[   16.271986] mptsas: ioc0: attaching sata device: fw_channel 0, fw_id 3, phy 1, sas_addr 0x677c605e9f919a95
[   16.284288] scsi 0:0:1:0: Direct-Access     ATA      GBRLB031XVECCM   4.26 PQ: 0 ANSI: 5
[   16.348106] qla2xxx [0000:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 8.04.00.03-k.
[   16.356369] qla2xxx [0000:24:00.0]-001d: : Found an ISP2532 irq 32 iobase 0xffffc9001e0ba000.
[   16.365364] qla2xxx 0000:24:00.0: irq 66 for MSI/MSI-X
[   16.370527] qla2xxx 0000:24:00.0: irq 67 for MSI/MSI-X
[   16.436226] scsi1 : qla2xxx
[   17.280685] qla2xxx [0000:24:00.0]-505f:1: Link is operational (2 Gbps).
[   17.780955] 
[   17.782450] =========================================================
[   17.784924] [ INFO: possible irq lock inversion dependency detected ]
[   17.784924] 3.6.0-0.0.0.28.36b5ec9-default #1 Not tainted
[   17.784924] ---------------------------------------------------------
[   17.784924] qla2xxx_1_dpc/368 just changed the state of lock:
[   17.784924]  (&(&ha->vport_slock)->rlock){+.....}, at: [<ffffffffa009b377>] qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
[   17.784924] but this lock was taken by another, HARDIRQ-safe lock in the past:
[   17.784924]  (&(&ha->hardware_lock)->rlock){-.....}

and interrupts could create inverse lock ordering between them.

[   17.784924] 
[   17.784924] other info that might help us debug this:
[   17.784924]  Possible interrupt unsafe locking scenario:
[   17.784924] 
[   17.784924]        CPU0                    CPU1
[   17.784924]        ----                    ----
[   17.784924]   lock(&(&ha->vport_slock)->rlock);
[   17.784924]                                local_irq_disable();
[   17.784924]                                lock(&(&ha->hardware_lock)->rlock);
[   17.784924]                                lock(&(&ha->vport_slock)->rlock);
[   17.784924]   <Interrupt>
[   17.784924]     lock(&(&ha->hardware_lock)->rlock);
[   17.784924] 
[   17.784924]  *** DEADLOCK ***
[   17.784924] 
[   17.784924] no locks held by qla2xxx_1_dpc/368.
[   17.784924] 
[   17.784924] the shortest dependencies between 2nd lock and 1st lock:
[   17.784924]  -> (&(&ha->hardware_lock)->rlock){-.....} ops: 49 {
[   17.784924]     IN-HARDIRQ-W at:
[   17.784924]                       [<ffffffff810ab36f>] mark_irqflags+0x17f/0x190
[   17.784924]                       [<ffffffff810aca0c>] __lock_acquire+0x35c/0x520
[   17.784924]                       [<ffffffff810acc6f>] lock_acquire+0x9f/0x190
[   17.784924]                       [<ffffffff814afdd4>] _raw_spin_lock_irqsave+0x54/0x70
[   17.784924]                       [<ffffffffa00b5a90>] qla24xx_msix_default+0x40/0x250 [qla2xxx]
[   17.784924]                       [<ffffffff810dd644>] handle_irq_event_percpu+0x84/0x3a0
[   17.784924]                       [<ffffffff810dd9a3>] handle_irq_event+0x43/0x70
[   17.784924]                       [<ffffffff810e0e6d>] handle_edge_irq+0x6d/0x130
[   17.784924]                       [<ffffffff810045ed>] handle_irq+0x1d/0x30
[   17.784924]                       [<ffffffff81003c98>] do_IRQ+0x58/0xe0
[   17.784924]                       [<ffffffff814b0a32>] ret_from_intr+0x0/0x1a
[   17.784924]                       [<ffffffff813a8c69>] cpuidle_enter+0x19/0x20
[   17.784924]                       [<ffffffff813a8c82>] cpuidle_enter_state+0x12/0x50
[   17.784924]                       [<ffffffff813a96c0>] cpuidle_idle_call+0xc0/0x260
[   17.784924]                       [<ffffffff8100af35>] cpu_idle+0x95/0xf0
[   17.784924]                       [<ffffffff8149459a>] rest_init+0xfa/0x170
[   17.784924]                       [<ffffffff81aeaeec>] start_kernel+0x3bf/0x3cc
[   17.784924]                       [<ffffffff81aea335>] x86_64_start_reservations+0x131/0x136
[   17.784924]                       [<ffffffff81aea43d>] x86_64_start_kernel+0x103/0x112
[   17.784924]     INITIAL USE at:
[   17.784924]                      [<ffffffff810ac88d>] __lock_acquire+0x1dd/0x520
[   17.784924]                      [<ffffffff810acc6f>] lock_acquire+0x9f/0x190
[   17.784924]                      [<ffffffff814afd68>] _raw_spin_lock_irq+0x48/0x60
[   17.784924]                      [<ffffffffa00b6b8c>] qla2x00_request_irqs+0x16c/0x2d0 [qla2xxx]
[   17.784924]                      [<ffffffffa00e1bb6>] qla2x00_probe_one+0xe15/0x225f [qla2xxx]
[   17.784924]                      [<ffffffff812a6b34>] local_pci_probe+0x74/0x100
[   17.784924]                      [<ffffffff812a6ca9>] __pci_device_probe+0xe9/0xf0
[   17.784924]                      [<ffffffff812a7f65>] pci_device_probe+0x35/0x60
[   17.784924]                      [<ffffffff8134e617>] really_probe+0x67/0x330
[   17.784924]                      [<ffffffff8134e922>] driver_probe_device+0x42/0xa0
[   17.784924]                      [<ffffffff8134ea23>] __driver_attach+0xa3/0xb0
[   17.784924]                      [<ffffffff8134c8a4>] bus_for_each_dev+0x64/0x90
[   17.784924]                      [<ffffffff8134e3d9>] driver_attach+0x19/0x20
[   17.784924]                      [<ffffffff8134de18>] bus_add_driver+0x208/0x290
[   17.784924]                      [<ffffffff8134f0af>] driver_register+0x6f/0x150
[   17.784924]                      [<ffffffff812a808c>] __pci_register_driver+0x5c/0x70
[   17.784924]                      [<ffffffffa01091cb>] qla2x00_module_init+0x1cb/0x21a [qla2xxx]
[   17.784924]                      [<ffffffff810001bd>] do_one_initcall+0x3d/0x170
[   17.784924]                      [<ffffffff810bafe6>] sys_init_module+0xc6/0x220
[   17.784924]                      [<ffffffff814b98b9>] system_call_fastpath+0x16/0x1b
[   17.784924]   }
[   17.784924]   ... key      at: [<ffffffffa00fb5a8>] __key.74145+0x0/0xfffffffffffe7a58 [qla2xxx]
[   17.784924]   ... acquired at:
[   17.784924]    [<ffffffff810ac5ac>] validate_chain+0x63c/0x740
[   17.784924]    [<ffffffff810ac9bd>] __lock_acquire+0x30d/0x520
[   17.784924]    [<ffffffff810acc6f>] lock_acquire+0x9f/0x190
[   17.784924]    [<ffffffff814afc8c>] _raw_spin_lock+0x3c/0x50
[   17.784924]    [<ffffffffa009b74d>] qla2x00_init_rings+0x11d/0x240 [qla2xxx]
[   17.784924]    [<ffffffffa009fad8>] qla2x00_initialize_adapter+0x3b8/0x3e0 [qla2xxx]
[   17.784924]    [<ffffffffa00e1dd2>] qla2x00_probe_one+0x1031/0x225f [qla2xxx]
[   17.784924]    [<ffffffff812a6b34>] local_pci_probe+0x74/0x100
[   17.784924]    [<ffffffff812a6ca9>] __pci_device_probe+0xe9/0xf0
[   17.784924]    [<ffffffff812a7f65>] pci_device_probe+0x35/0x60
[   17.784924]    [<ffffffff8134e617>] really_probe+0x67/0x330
[   17.784924]    [<ffffffff8134e922>] driver_probe_device+0x42/0xa0
[   17.784924]    [<ffffffff8134ea23>] __driver_attach+0xa3/0xb0
[   17.784924]    [<ffffffff8134c8a4>] bus_for_each_dev+0x64/0x90
[   17.784924]    [<ffffffff8134e3d9>] driver_attach+0x19/0x20
[   17.784924]    [<ffffffff8134de18>] bus_add_driver+0x208/0x290
[   17.784924]    [<ffffffff8134f0af>] driver_register+0x6f/0x150
[   17.784924]    [<ffffffff812a808c>] __pci_register_driver+0x5c/0x70
[   17.784924]    [<ffffffffa01091cb>] qla2x00_module_init+0x1cb/0x21a [qla2xxx]
[   17.784924]    [<ffffffff810001bd>] do_one_initcall+0x3d/0x170
[   17.784924]    [<ffffffff810bafe6>] sys_init_module+0xc6/0x220
[   17.784924]    [<ffffffff814b98b9>] system_call_fastpath+0x16/0x1b
[   17.784924] 
[   17.784924] -> (&(&ha->vport_slock)->rlock){+.....} ops: 2 {
[   17.784924]    HARDIRQ-ON-W at:
[   17.784924]                     [<ffffffff810ab320>] mark_irqflags+0x130/0x190
[   17.784924]                     [<ffffffff810aca0c>] __lock_acquire+0x35c/0x520
[   17.784924]                     [<ffffffff810acc6f>] lock_acquire+0x9f/0x190
[   17.784924]                     [<ffffffff814afc8c>] _raw_spin_lock+0x3c/0x50
[   17.784924]                     [<ffffffffa009b377>] qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
[   17.784924]                     [<ffffffffa00a2060>] qla2x00_configure_loop+0x30/0x2f0 [qla2xxx]
[   17.784924]                     [<ffffffffa00a27d6>] qla2x00_loop_resync+0x126/0x160 [qla2xxx]
[   17.784924]                     [<ffffffffa00994de>] qla2x00_do_dpc+0x5ee/0x660 [qla2xxx]
[   17.784924]                     [<ffffffff8106cc26>] kthread+0xd6/0xe0
[   17.784924]                     [<ffffffff814bab24>] kernel_thread_helper+0x4/0x10
[   17.784924]    INITIAL USE at:
[   17.784924]                    [<ffffffff810ac88d>] __lock_acquire+0x1dd/0x520
[   17.784924]                    [<ffffffff810acc6f>] lock_acquire+0x9f/0x190
[   17.784924]                    [<ffffffff814afc8c>] _raw_spin_lock+0x3c/0x50
[   17.784924]                    [<ffffffffa009b74d>] qla2x00_init_rings+0x11d/0x240 [qla2xxx]
[   17.784924]                    [<ffffffffa009fad8>] qla2x00_initialize_adapter+0x3b8/0x3e0 [qla2xxx]
[   17.784924]                    [<ffffffffa00e1dd2>] qla2x00_probe_one+0x1031/0x225f [qla2xxx]
[   17.784924]                    [<ffffffff812a6b34>] local_pci_probe+0x74/0x100
[   17.784924]                    [<ffffffff812a6ca9>] __pci_device_probe+0xe9/0xf0
[   17.784924]                    [<ffffffff812a7f65>] pci_device_probe+0x35/0x60
[   17.784924]                    [<ffffffff8134e617>] really_probe+0x67/0x330
[   17.784924]                    [<ffffffff8134e922>] driver_probe_device+0x42/0xa0
[   17.784924]                    [<ffffffff8134ea23>] __driver_attach+0xa3/0xb0
[   17.784924]                    [<ffffffff8134c8a4>] bus_for_each_dev+0x64/0x90
[   17.784924]                    [<ffffffff8134e3d9>] driver_attach+0x19/0x20
[   17.784924]                    [<ffffffff8134de18>] bus_add_driver+0x208/0x290
[   17.784924]                    [<ffffffff8134f0af>] driver_register+0x6f/0x150
[   17.784924]                    [<ffffffff812a808c>] __pci_register_driver+0x5c/0x70
[   17.784924]                    [<ffffffffa01091cb>] qla2x00_module_init+0x1cb/0x21a [qla2xxx]
[   17.784924]                    [<ffffffff810001bd>] do_one_initcall+0x3d/0x170
[   17.784924]                    [<ffffffff810bafe6>] sys_init_module+0xc6/0x220
[   17.784924]                    [<ffffffff814b98b9>] system_call_fastpath+0x16/0x1b
[   17.784924]  }
[   17.784924]  ... key      at: [<ffffffffa00fb5a0>] __key.74146+0x0/0xfffffffffffe7a60 [qla2xxx]
[   17.784924]  ... acquired at:
[   17.784924]    [<ffffffff810aa43a>] check_usage_backwards+0x8a/0xf0
[   17.784924]    [<ffffffff810aadf9>] mark_lock_irq+0x99/0x290
[   17.784924]    [<ffffffff810ab13e>] mark_lock+0x14e/0x200
[   17.784924]    [<ffffffff810ab320>] mark_irqflags+0x130/0x190
[   17.784924]    [<ffffffff810aca0c>] __lock_acquire+0x35c/0x520
[   17.784924]    [<ffffffff810acc6f>] lock_acquire+0x9f/0x190
[   17.784924]    [<ffffffff814afc8c>] _raw_spin_lock+0x3c/0x50
[   17.784924]    [<ffffffffa009b377>] qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
[   17.784924]    [<ffffffffa00a2060>] qla2x00_configure_loop+0x30/0x2f0 [qla2xxx]
[   17.784924]    [<ffffffffa00a27d6>] qla2x00_loop_resync+0x126/0x160 [qla2xxx]
[   17.784924]    [<ffffffffa00994de>] qla2x00_do_dpc+0x5ee/0x660 [qla2xxx]
[   17.784924]    [<ffffffff8106cc26>] kthread+0xd6/0xe0
[   17.784924]    [<ffffffff814bab24>] kernel_thread_helper+0x4/0x10
[   17.784924] 
[   17.784924] 
[   17.784924] stack backtrace:
[   17.784924] Pid: 368, comm: qla2xxx_1_dpc Not tainted 3.6.0-0.0.0.28.36b5ec9-default #1
[   17.784924] Call Trace:
[   17.784924]  [<ffffffff810a9ce6>] print_irq_inversion_bug+0x1c6/0x210
[   17.784924]  [<ffffffff810aa43a>] check_usage_backwards+0x8a/0xf0
[   17.784924]  [<ffffffff814b05cb>] ? _raw_spin_unlock_irqrestore+0x3b/0x80
[   17.784924]  [<ffffffff810aa3b0>] ? print_usage_bug+0x190/0x190
[   17.784924]  [<ffffffff810aadf9>] mark_lock_irq+0x99/0x290
[   17.784924]  [<ffffffff810ab13e>] mark_lock+0x14e/0x200
[   17.784924]  [<ffffffff810ab320>] mark_irqflags+0x130/0x190
[   17.784924]  [<ffffffff810aca0c>] __lock_acquire+0x35c/0x520
[   17.784924]  [<ffffffff810acc6f>] lock_acquire+0x9f/0x190
[   17.784924]  [<ffffffffa009b377>] ? qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
[   17.784924]  [<ffffffff814afc8c>] _raw_spin_lock+0x3c/0x50
[   17.784924]  [<ffffffffa009b377>] ? qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
[   17.784924]  [<ffffffffa009b377>] qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
[   17.784924]  [<ffffffff810ab700>] ? trace_hardirqs_on_caller+0xb0/0x1a0
[   17.784924]  [<ffffffffa00a2060>] qla2x00_configure_loop+0x30/0x2f0 [qla2xxx]
[   17.784924]  [<ffffffffa00a27d6>] qla2x00_loop_resync+0x126/0x160 [qla2xxx]
[   17.784924]  [<ffffffffa00994de>] qla2x00_do_dpc+0x5ee/0x660 [qla2xxx]
[   17.784924]  [<ffffffffa0098ef0>] ? qla2x00_relogin+0x220/0x220 [qla2xxx]
[   17.784924]  [<ffffffff8106cc26>] kthread+0xd6/0xe0
[   17.784924]  [<ffffffff814b056b>] ? _raw_spin_unlock_irq+0x2b/0x50
[   17.784924]  [<ffffffff814bab24>] kernel_thread_helper+0x4/0x10
[   17.784924]  [<ffffffff814b0af3>] ? retint_restore_args+0x13/0x13
[   17.784924]  [<ffffffff8106cb50>] ? __init_kthread_worker+0x70/0x70
[   17.784924]  [<ffffffff814bab20>] ? gs_change+0x13/0x13
[   18.928207] qla2xxx [0000:24:00.0]-00fb:1: QLogic QMI2572 - QLogic 4Gb Fibre Channel Expansion Card (CIOv) for IBM BladeCenter.
[   18.939685] qla2xxx [0000:24:00.0]-00fc:1: ISP2532: PCIe (5.0GT/s x8) @ 0000:24:00.0 hdma+ host#=1 fw=5.06.05 (90d5).
[   18.951022] qla2xxx [0000:24:00.1]-001d: : Found an ISP2532 irq 42 iobase 0xffffc9001e2a0000.
[   18.959964] qla2xxx 0000:24:00.1: irq 68 for MSI/MSI-X
[   18.965162] qla2xxx 0000:24:00.1: irq 69 for MSI/MSI-X
[   19.023894] scsi2 : qla2xxx
[   19.888618] scsi 1:0:0:0: Direct-Access     IBM      1724-100  FAStT  0542 PQ: 0 ANSI: 3
[   19.901563] scsi 1:0:0:1: Direct-Access     IBM      1724-100  FAStT  0542 PQ: 0 ANSI: 3
[   19.910274] scsi 1:0:0:2: Direct-Access     IBM      1724-100  FAStT  0542 PQ: 0 ANSI: 3
[   19.918951] scsi 1:0:0:3: Direct-Access     IBM      1724-100  FAStT  0542 PQ: 0 ANSI: 3
[   19.927742] scsi 1:0:0:4: Direct-Access     IBM      1724-100  FAStT  0542 PQ: 0 ANSI: 3
[   19.936460] scsi 1:0:0:5: Direct-Access     IBM      1724-100  FAStT  0542 PQ: 0 ANSI: 3
[   19.945269] scsi 1:0:0:6: Direct-Access     IBM      1724-100  FAStT  0542 PQ: 0 ANSI: 3
[   19.953995] scsi 1:0:0:31: Direct-Access     IBM      Universal Xport  0542 PQ: 0 ANSI: 3
[   19.963750] scsi 1:0:1:0: Direct-Access     IBM      1724-100  FAStT  0542 PQ: 0 ANSI: 3
[   19.976798] scsi 1:0:1:1: Direct-Access     IBM      1724-100  FAStT  0542 PQ: 0 ANSI: 3
[   19.985520] scsi 1:0:1:2: Direct-Access     IBM      1724-100  FAStT  0542 PQ: 0 ANSI: 3
[   19.994223] scsi 1:0:1:3: Direct-Access     IBM      1724-100  FAStT  0542 PQ: 0 ANSI: 3
[   20.002872] scsi 1:0:1:4: Direct-Access     IBM      1724-100  FAStT  0542 PQ: 0 ANSI: 3
[   20.011658] scsi 1:0:1:5: Direct-Access     IBM      1724-100  FAStT  0542 PQ: 0 ANSI: 3
[   20.020233] scsi 1:0:1:6: Direct-Access     IBM      1724-100  FAStT  0542 PQ: 0 ANSI: 3
[   20.028905] scsi 1:0:1:31: Direct-Access     IBM      Universal Xport  0542 PQ: 0 ANSI: 3
[   24.028195] qla2xxx [0000:24:00.1]-00fb:2: QLogic QMI2572 - QLogic 4Gb Fibre Channel Expansion Card (CIOv) for IBM BladeCenter.
[   24.039718] qla2xxx [0000:24:00.1]-00fc:2: ISP2532: PCIe (5.0GT/s x8) @ 0000:24:00.1 hdma+ host#=2 fw=5.06.05 (90d5).
[   24.084241] ACPI: bus type usb registered
#1 lore raw
Quoted 26 lines · Srivatsa S. Bhat

With the mainline kernel (in the merge window) I am seeing the following lockdep splat every time during boot.

Regards,
Srivatsa S. Bhat

------------------------------------>

[    3.940316] SCSI subsystem initialized
[    3.949021] Fusion MPT base driver 3.04.20
[    3.953141] Copyright (c) 1999-2008 LSI Corporation
[    3.955471] Fusion MPT SAS Host driver 3.04.20
[    3.955850] mptbase: ioc0: Initiating bringup
[    4.656179] ioc0: LSISAS1064E B3: Capabilities={Initiator}
[   16.216323] scsi0 : ioc0: LSISAS1064E B3, FwRev=011e0000h, Ports=1, MaxQ=277, IRQ=28
[   16.248414] mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 1, phy 0, sas_addr 0x5000c5001d7e18c9
[   16.259708] scsi 0:0:0:0: Direct-Access     IBM-ESXS ST9146803SS      B536 PQ: 0 ANSI: 5
[   16.271986] mptsas: ioc0: attaching sata device: fw_channel 0, fw_id 3, phy 1, sas_addr 0x677c605e9f919a95
[   16.284288] scsi 0:0:1:0: Direct-Access     ATA      GBRLB031XVECCM   4.26 PQ: 0 ANSI: 5
[   16.348106] qla2xxx [0000:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 8.04.00.03-k.
[   16.356369] qla2xxx [0000:24:00.0]-001d: : Found an ISP2532 irq 32 iobase 0xffffc9001e0ba000.
[   16.365364] qla2xxx 0000:24:00.0: irq 66 for MSI/MSI-X
[   16.370527] qla2xxx 0000:24:00.0: irq 67 for MSI/MSI-X
[   16.436226] scsi1 : qla2xxx
[   17.280685] qla2xxx [0000:24:00.0]-505f:1: Link is operational (2 Gbps).
[   17.780955] 
Quoted 8 lines
[   17.782450] =========================================================
[   17.784924] [ INFO: possible irq lock inversion dependency detected ]
[   17.784924] 3.6.0-0.0.0.28.36b5ec9-default #1 Not tainted
[   17.784924] ---------------------------------------------------------
[   17.784924] qla2xxx_1_dpc/368 just changed the state of lock:
[   17.784924]  (&(&ha->vport_slock)->rlock){+.....}, at: [<ffffffffa009b377>] qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
[   17.784924] but this lock was taken by another, HARDIRQ-safe lock in the past:
[   17.784924]  (&(&ha->hardware_lock)->rlock){-.....}

This seems to be real. You should be seeing that since 3.5-rc1 already though ... ?

Does the patch below fix that?

From: Jiri Kosina <[email protected]>
Subject: [PATCH] [SCSI] qla2xxx: fix potential deadlock on ha->hardware_lock

Lockdep reports:

=== [ cut here ] ===
=========================================================
[ INFO: possible irq lock inversion dependency detected ]
3.6.0-0.0.0.28.36b5ec9-default #1 Not tainted
---------------------------------------------------------
qla2xxx_1_dpc/368 just changed the state of lock:
(&(&ha->vport_slock)->rlock){+.....}, at: [<ffffffffa009b377>] qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
but this lock was taken by another, HARDIRQ-safe lock in the past:
(&(&ha->hardware_lock)->rlock){-.....}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&(&ha->vport_slock)->rlock);
                               local_irq_disable();
                               lock(&(&ha->hardware_lock)->rlock);
                               lock(&(&ha->vport_slock)->rlock);
  <Interrupt>
    lock(&(&ha->hardware_lock)->rlock);

=== [ cut here ] ===

Fix the potential deadlock by disabling IRQs while holding ha->vport_slock.

---
 drivers/scsi/qla2xxx/qla_init.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)
drivers/scsi/qla2xxx/qla_init.c +3 -2
index 799a58b..48fca47 100644
@@ -2080,6 +2080,7 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
 	uint8_t       domain;
 	char		connect_type[22];
 	struct qla_hw_data *ha = vha->hw;
+	unsigned long flags;
 
 	/* Get host addresses. */
 	rval = qla2x00_get_adapter_id(vha,
@@ -2154,9 +2155,9 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
 	vha->d_id.b.area = area;
 	vha->d_id.b.al_pa = al_pa;
 
-	spin_lock(&ha->vport_slock);
+	spin_lock_irqsave(&ha->vport_slock, flags);
 	qlt_update_vp_map(vha, SET_AL_PA);
-	spin_unlock(&ha->vport_slock);
+	spin_unlock_irqrestore(&ha->vport_slock, flags);
 
 	if (!vha->flags.init_done)
 		ql_log(ql_log_info, vha, 0x2010,
Signature · 2 lines
Jiri Kosina
SUSE Labs
author Tested-by
#2 lore raw

Hi Jiri,

Thanks for taking a look!

Quoted 5 lines

This seems to be real. You should be seeing that since 3.5-rc1 already though ... ?

Does the patch below fix that?

Yes, it does, thanks! But 3.6-rc kernels were booting fine as far as I remember. I'll check again and get back tomorrow.

Quoted 29 lines

From: Jiri Kosina <[email protected]>
Subject: [PATCH] [SCSI] qla2xxx: fix potential deadlock on ha->hardware_lock

Lockdep reports:

=== [ cut here ] ===
=========================================================
[ INFO: possible irq lock inversion dependency detected ]
3.6.0-0.0.0.28.36b5ec9-default #1 Not tainted
---------------------------------------------------------
qla2xxx_1_dpc/368 just changed the state of lock:
(&(&ha->vport_slock)->rlock){+.....}, at: [<ffffffffa009b377>] qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
but this lock was taken by another, HARDIRQ-safe lock in the past:
(&(&ha->hardware_lock)->rlock){-.....}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&(&ha->vport_slock)->rlock);
                               local_irq_disable();
                               lock(&(&ha->hardware_lock)->rlock);
                               lock(&(&ha->vport_slock)->rlock);
  <Interrupt>
    lock(&(&ha->hardware_lock)->rlock);
Quoted 6 lines

=== [ cut here ] ===

Fix the potential deadlock by disabling IRQs while holding ha->vport_slock.

Regards,
Srivatsa S. Bhat

Quoted 29 lines
---
 drivers/scsi/qla2xxx/qla_init.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)
drivers/scsi/qla2xxx/qla_init.c +3 -2
index 799a58b..48fca47 100644
@@ -2080,6 +2080,7 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
 	uint8_t       domain;
 	char		connect_type[22];
 	struct qla_hw_data *ha = vha->hw;
+	unsigned long flags;
 
 	/* Get host addresses. */
 	rval = qla2x00_get_adapter_id(vha,
@@ -2154,9 +2155,9 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
 	vha->d_id.b.area = area;
 	vha->d_id.b.al_pa = al_pa;
 
-	spin_lock(&ha->vport_slock);
+	spin_lock_irqsave(&ha->vport_slock, flags);
 	qlt_update_vp_map(vha, SET_AL_PA);
-	spin_unlock(&ha->vport_slock);
+	spin_unlock_irqrestore(&ha->vport_slock, flags);
 
 	if (!vha->flags.init_done)
 		ql_log(ql_log_info, vha, 0x2010,
#3 lore raw
Quoted 3 lines · Srivatsa S. Bhat

Hi Jiri,

Thanks for taking a look!

Hi Srivatsa & Jiri,

Quoted 10 lines
Quoted 6 lines

This seems to be real. You should be seeing that since 3.5-rc1 already though ... ?

Does the patch below fix that?

Yes, it does, thanks! But 3.6-rc kernels were booting fine as far as I remember. I'll check again and get back tomorrow.

Thanks for testing with v3.7-rc0 code !

Cc'ing the Qlogic folks here, as this irq lock inversion warning appears to be regression from v3.7-rc1 qla2xxx (initiator) LLD changes that went in recently via scsi.git.

Thanks,

--nab

Quoted 75 lines
Quoted 29 lines

From: Jiri Kosina <[email protected]>
Subject: [PATCH] [SCSI] qla2xxx: fix potential deadlock on ha->hardware_lock

Lockdep reports:

=== [ cut here ] ===
=========================================================
[ INFO: possible irq lock inversion dependency detected ]
3.6.0-0.0.0.28.36b5ec9-default #1 Not tainted
---------------------------------------------------------
qla2xxx_1_dpc/368 just changed the state of lock:
(&(&ha->vport_slock)->rlock){+.....}, at: [<ffffffffa009b377>] qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
but this lock was taken by another, HARDIRQ-safe lock in the past:
(&(&ha->hardware_lock)->rlock){-.....}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&(&ha->vport_slock)->rlock);
                               local_irq_disable();
                               lock(&(&ha->hardware_lock)->rlock);
                               lock(&(&ha->vport_slock)->rlock);
  <Interrupt>
    lock(&(&ha->hardware_lock)->rlock);
Quoted 6 lines

=== [ cut here ] ===

Fix the potential deadlock by disabling IRQs while holding ha->vport_slock.

Regards,
Srivatsa S. Bhat

Quoted 19 lines
---
 drivers/scsi/qla2xxx/qla_init.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)
drivers/scsi/qla2xxx/qla_init.c +1 -0
index 799a58b..48fca47 100644
@@ -2080,6 +2080,7 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
 	uint8_t       domain;
 	char		connect_type[22];
 	struct qla_hw_data *ha = vha->hw;
+	unsigned long flags;
 
 	/* Get host addresses. */
 	rval = qla2x00_get_adapter_id(vha,
@@ -2154,9 +2155,9 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
 	vha->d_id.b.area = area;

drivers/scsi/qla2xxx/qla_init.c qla2x00_configure_hba(scsi_qla_host_t *vha) · line 2163

Quoted 10 lines
drivers/scsi/qla2xxx/qla_init.c +2 -2
 	vha->d_id.b.al_pa = al_pa;
 
-	spin_lock(&ha->vport_slock);
+	spin_lock_irqsave(&ha->vport_slock, flags);
 	qlt_update_vp_map(vha, SET_AL_PA);
-	spin_unlock(&ha->vport_slock);
+	spin_unlock_irqrestore(&ha->vport_slock, flags);
 
 	if (!vha->flags.init_done)
 		ql_log(ql_log_info, vha, 0x2010,

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#4 lore raw

Hi Nicholas,

Quoted 18 lines · Nicholas A. Bellinger
Quoted 3 lines · Srivatsa S. Bhat

Hi Jiri,

Thanks for taking a look!

Hi Srivatsa & Jiri,

Quoted 10 lines
Quoted 6 lines

This seems to be real. You should be seeing that since 3.5-rc1 already though ... ?

Does the patch below fix that?

Yes, it does, thanks! But 3.6-rc kernels were booting fine as far as I remember. I'll check again and get back tomorrow.

Quoted 6 lines

Thanks for testing with v3.7-rc0 code !

Cc'ing the Qlogic folks here, as this irq lock inversion warning appears to be regression from v3.7-rc1 qla2xxx (initiator) LLD changes that went in recently via scsi.git.

Actually Jiri is right - I am seeing this with 3.5-rc1 kernel also. So its not a regression from this merge window.. it was there all along!

Regards,
Srivatsa S. Bhat

Quoted 72 lines
Quoted 72 lines
Quoted 30 lines

From: Jiri Kosina <[email protected]>
Subject: [PATCH] [SCSI] qla2xxx: fix potential deadlock on ha->hardware_lock

Lockdep reports:

=== [ cut here ] ===
=========================================================
[ INFO: possible irq lock inversion dependency detected ]
3.6.0-0.0.0.28.36b5ec9-default #1 Not tainted
---------------------------------------------------------
qla2xxx_1_dpc/368 just changed the state of lock:
(&(&ha->vport_slock)->rlock){+.....}, at: [<ffffffffa009b377>] qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
but this lock was taken by another, HARDIRQ-safe lock in the past:
(&(&ha->hardware_lock)->rlock){-.....}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&(&ha->vport_slock)->rlock);
                               local_irq_disable();
                               lock(&(&ha->hardware_lock)->rlock);
                               lock(&(&ha->vport_slock)->rlock);
  <Interrupt>
    lock(&(&ha->hardware_lock)->rlock);
Quoted 6 lines

=== [ cut here ] ===

Fix the potential deadlock by disabling IRQs while holding ha->vport_slock.

Regards,
Srivatsa S. Bhat

Quoted 29 lines
---
 drivers/scsi/qla2xxx/qla_init.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)
drivers/scsi/qla2xxx/qla_init.c +3 -2
index 799a58b..48fca47 100644
@@ -2080,6 +2080,7 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
 	uint8_t       domain;
 	char		connect_type[22];
 	struct qla_hw_data *ha = vha->hw;
+	unsigned long flags;
 
 	/* Get host addresses. */
 	rval = qla2x00_get_adapter_id(vha,
@@ -2154,9 +2155,9 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
 	vha->d_id.b.area = area;
 	vha->d_id.b.al_pa = al_pa;
 
-	spin_lock(&ha->vport_slock);
+	spin_lock_irqsave(&ha->vport_slock, flags);
 	qlt_update_vp_map(vha, SET_AL_PA);
-	spin_unlock(&ha->vport_slock);
+	spin_unlock_irqrestore(&ha->vport_slock, flags);
 
 	if (!vha->flags.init_done)
 		ql_log(ql_log_info, vha, 0x2010,
#5 lore raw

PATCH RESEND 1/1 qla2xxx: fix potential deadlock on ha->hardware_lock

In reply to Jiri Kosina

Lockdep reports:

=== [ cut here ] ===
=========================================================
[ INFO: possible irq lock inversion dependency detected ]
3.6.0-0.0.0.28.36b5ec9-default #1 Not tainted
---------------------------------------------------------
qla2xxx_1_dpc/368 just changed the state of lock:
(&(&ha->vport_slock)->rlock){+.....}, at: [<ffffffffa009b377>] qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
but this lock was taken by another, HARDIRQ-safe lock in the past:
(&(&ha->hardware_lock)->rlock){-.....}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&(&ha->vport_slock)->rlock);
                               local_irq_disable();
                               lock(&(&ha->hardware_lock)->rlock);
                               lock(&(&ha->vport_slock)->rlock);
  <Interrupt>
    lock(&(&ha->hardware_lock)->rlock);

=== [ cut here ] ===

Fix the potential deadlock by disabling IRQs while holding ha->vport_slock.

---
 drivers/scsi/qla2xxx/qla_init.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)
drivers/scsi/qla2xxx/qla_init.c +3 -2
index 799a58b..48fca47 100644
@@ -2080,6 +2080,7 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
 	uint8_t       domain;
 	char		connect_type[22];
 	struct qla_hw_data *ha = vha->hw;
+	unsigned long flags;
 
 	/* Get host addresses. */
 	rval = qla2x00_get_adapter_id(vha,
@@ -2154,9 +2155,9 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
 	vha->d_id.b.area = area;
 	vha->d_id.b.al_pa = al_pa;
 
-	spin_lock(&ha->vport_slock);
+	spin_lock_irqsave(&ha->vport_slock, flags);
 	qlt_update_vp_map(vha, SET_AL_PA);
-	spin_unlock(&ha->vport_slock);
+	spin_unlock_irqrestore(&ha->vport_slock, flags);
 
 	if (!vha->flags.init_done)
 		ql_log(ql_log_info, vha, 0x2010,
Signature · 2 lines
Jiri Kosina
SUSE Labs
#6 lore raw

Re: [PATCH] [RESEND] qla2xxx: fix potential deadlock on ha->hardware_lock

Quoted 25 lines · Jiri Kosina

Lockdep reports:

=== [ cut here ] ===
=========================================================
[ INFO: possible irq lock inversion dependency detected ]
3.6.0-0.0.0.28.36b5ec9-default #1 Not tainted
---------------------------------------------------------
qla2xxx_1_dpc/368 just changed the state of lock:
(&(&ha->vport_slock)->rlock){+.....}, at: [<ffffffffa009b377>] qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
but this lock was taken by another, HARDIRQ-safe lock in the past:
(&(&ha->hardware_lock)->rlock){-.....}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&(&ha->vport_slock)->rlock);
                               local_irq_disable();
                               lock(&(&ha->hardware_lock)->rlock);
                               lock(&(&ha->vport_slock)->rlock);
  <Interrupt>
    lock(&(&ha->hardware_lock)->rlock);
Quoted 6 lines

=== [ cut here ] ===

Fix the potential deadlock by disabling IRQs while holding ha->vport_slock.

This needs a CC to stable also right?

Regards,
Srivatsa S. Bhat

Quoted 29 lines
---
 drivers/scsi/qla2xxx/qla_init.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)
drivers/scsi/qla2xxx/qla_init.c +3 -2
index 799a58b..48fca47 100644
@@ -2080,6 +2080,7 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
 	uint8_t       domain;
 	char		connect_type[22];
 	struct qla_hw_data *ha = vha->hw;
+	unsigned long flags;
 
 	/* Get host addresses. */
 	rval = qla2x00_get_adapter_id(vha,
@@ -2154,9 +2155,9 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
 	vha->d_id.b.area = area;
 	vha->d_id.b.al_pa = al_pa;
 
-	spin_lock(&ha->vport_slock);
+	spin_lock_irqsave(&ha->vport_slock, flags);
 	qlt_update_vp_map(vha, SET_AL_PA);
-	spin_unlock(&ha->vport_slock);
+	spin_unlock_irqrestore(&ha->vport_slock, flags);
 
 	if (!vha->flags.init_done)
 		ql_log(ql_log_info, vha, 0x2010,
Signature · 2 lines
Regards,
Srivatsa S. Bhat
Acked-by on v1 1/1
#7 lore raw

Re: [PATCH] [RESEND] qla2xxx: fix potential deadlock on ha->hardware_lock

In reply to Jiri Kosina

Thanks,
~Saurav

Quoted 65 lines

Lockdep reports:

=== [ cut here ] ===
=========================================================
[ INFO: possible irq lock inversion dependency detected ] 3.6.0-0.0.0.28.36b5ec9-default #1 Not tainted
---------------------------------------------------------
qla2xxx_1_dpc/368 just changed the state of lock:
(&(&ha->vport_slock)->rlock){+.....}, at: [<ffffffffa009b377>]
qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
but this lock was taken by another, HARDIRQ-safe lock in the past:
(&(&ha->hardware_lock)->rlock){-.....}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
Possible interrupt unsafe locking scenario:

      CPU0                    CPU1
      ----                    ----
 lock(&(&ha->vport_slock)->rlock);
                              local_irq_disable();
                              lock(&(&ha->hardware_lock)->rlock);
                              lock(&(&ha->vport_slock)->rlock);

<Interrupt>
lock(&(&ha->hardware_lock)->rlock);
=== [ cut here ] ===

Fix the potential deadlock by disabling IRQs while holding ha->vport_slock.

Reported-and-tested-by: Srivatsa S. Bhat
<[email protected]>

---
drivers/scsi/qla2xxx/qla_init.c | 5 +++--

1 files changed, 3 insertions(+), 2 deletions(-)
drivers/scsi/qla2xxx/qla_init.c +3 -3
index 799a58b..48fca47 100644
@@ -2080,6 +2080,7 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
      uint8_t       domain;
      char            connect_type[22];
      struct qla_hw_data *ha = vha->hw;
+      unsigned long flags;
 
      /* Get host addresses. */
      rval = qla2x00_get_adapter_id(vha,
@@ -2154,9 +2155,9 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
      vha->d_id.b.area = area;
      vha->d_id.b.al_pa = al_pa;
 
-      spin_lock(&ha->vport_slock);
+      spin_lock_irqsave(&ha->vport_slock, flags);
      qlt_update_vp_map(vha, SET_AL_PA);
-      spin_unlock(&ha->vport_slock);
+      spin_unlock_irqrestore(&ha->vport_slock, flags);
 
      if (!vha->flags.init_done)
              ql_log(ql_log_info, vha, 0x2010,
 
--
Quoted 7 lines

Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.

#8 lore raw

Re: [PATCH] [RESEND] qla2xxx: fix potential deadlock on ha->hardware_lock

In reply to Jiri Kosina

Hi Jiri, Andrew, Arun & Co,

Quoted 25 lines · Jiri Kosina

Lockdep reports:

=== [ cut here ] ===
=========================================================
[ INFO: possible irq lock inversion dependency detected ]
3.6.0-0.0.0.28.36b5ec9-default #1 Not tainted
---------------------------------------------------------
qla2xxx_1_dpc/368 just changed the state of lock:
(&(&ha->vport_slock)->rlock){+.....}, at: [<ffffffffa009b377>] qla2x00_configure_hba+0x197/0x3c0 [qla2xxx]
but this lock was taken by another, HARDIRQ-safe lock in the past:
(&(&ha->hardware_lock)->rlock){-.....}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&(&ha->vport_slock)->rlock);
                               local_irq_disable();
                               lock(&(&ha->hardware_lock)->rlock);
                               lock(&(&ha->vport_slock)->rlock);
  <Interrupt>
    lock(&(&ha->hardware_lock)->rlock);
Quoted 7 lines

=== [ cut here ] ===

Fix the potential deadlock by disabling IRQs while holding ha->vport_slock.

---

I'm fine with this patch and have applied to target-pending/queue for the moment.

It will be moved into /master + included in the next PULL request once Linus merges the outstanding /for-next series into -rc0 code.

Also please have a look below for a few more related items I noticed while reviewing this patch..

Quoted 18 lines
 drivers/scsi/qla2xxx/qla_init.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)
drivers/scsi/qla2xxx/qla_init.c +1 -0
index 799a58b..48fca47 100644
@@ -2080,6 +2080,7 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
 	uint8_t       domain;
 	char		connect_type[22];
 	struct qla_hw_data *ha = vha->hw;
+	unsigned long flags;
 
 	/* Get host addresses. */
 	rval = qla2x00_get_adapter_id(vha,
@@ -2154,9 +2155,9 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
 	vha->d_id.b.area = area;

drivers/scsi/qla2xxx/qla_init.c qla2x00_configure_hba(scsi_qla_host_t *vha) · line 2163

Quoted 10 lines
drivers/scsi/qla2xxx/qla_init.c +2 -2
 	vha->d_id.b.al_pa = al_pa;
 
-	spin_lock(&ha->vport_slock);
+	spin_lock_irqsave(&ha->vport_slock, flags);
 	qlt_update_vp_map(vha, SET_AL_PA);
-	spin_unlock(&ha->vport_slock);
+	spin_unlock_irqrestore(&ha->vport_slock, flags);
 
 	if (!vha->flags.init_done)
 		ql_log(ql_log_info, vha, 0x2010,

So while looking at other ->vport_slock + qlt_update_vp_map() usage, two more items caught my eye:

In qla_mid.c:qla24xx_disable_vp() code:

        ret = qla24xx_control_vp(vha, VCE_COMMAND_DISABLE_VPS_LOGO_ALL);
        atomic_set(&vha->loop_state, LOOP_DOWN);
        atomic_set(&vha->loop_down_timer, LOOP_DOWN_TIME);
 
        /* Remove port id from vp target map */
        qlt_update_vp_map(vha, RESET_AL_PA);
 
        qla2x00_mark_vp_devices_dead(vha);
        atomic_set(&vha->vp_state, VP_FAILED);

AFAICT all callers of qlt_update_vp_map() into qla_target.c code should be holding ->vport_slock. I'll send out a separate patch for this shortly.

And in qla_init.c:qla2x00_init_rings() code:

        for (que = 0; que < ha->max_rsp_queues; que++) {
                rsp = ha->rsp_q_map[que];
                if (!rsp)
                        continue;
                /* Initialize response queue entries */
                qla2x00_init_response_q_entries(rsp);
        }

        spin_lock(&ha->vport_slock);

        spin_unlock(&ha->vport_slock);

        ha->tgt.atio_ring_ptr = ha->tgt.atio_ring;
        ha->tgt.atio_ring_index = 0;
        /* Initialize ATIO queue entries */
        qlt_init_atio_q_entries(vha);

The usage of ->vport_slock seems to be now either unnecessary, or a result of some bad merge outside of qla2xxx target mode.

Qlogic folks, can this (leftover..?) usage of ->vport_slock now be safety removed..?

--nab

#9 lore raw

Re: [PATCH] [RESEND] qla2xxx: fix potential deadlock on ha->hardware_lock

Hi Nick,

Quoted 2 lines · Nicholas A. Bellinger

Hi Jiri, Andrew, Arun & Co,

--8<-- snipped --

Quoted 48 lines

Also please have a look below for a few more related items I noticed while reviewing this patch..

Quoted 18 lines
 drivers/scsi/qla2xxx/qla_init.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)
drivers/scsi/qla2xxx/qla_init.c +1 -0
index 799a58b..48fca47 100644
@@ -2080,6 +2080,7 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
     uint8_t       domain;
     char            connect_type[22];
     struct qla_hw_data *ha = vha->hw;
+    unsigned long flags;
 
     /* Get host addresses. */
     rval = qla2x00_get_adapter_id(vha,
@@ -2154,9 +2155,9 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
     vha->d_id.b.area = area;

drivers/scsi/qla2xxx/qla_init.c qla2x00_configure_hba(scsi_qla_host_t *vha) · line 2163

Quoted 10 lines
drivers/scsi/qla2xxx/qla_init.c +2 -2
     vha->d_id.b.al_pa = al_pa;
 
-    spin_lock(&ha->vport_slock);
+    spin_lock_irqsave(&ha->vport_slock, flags);
     qlt_update_vp_map(vha, SET_AL_PA);
-    spin_unlock(&ha->vport_slock);
+    spin_unlock_irqrestore(&ha->vport_slock, flags);
 
     if (!vha->flags.init_done)
             ql_log(ql_log_info, vha, 0x2010,

So while looking at other ->vport_slock + qlt_update_vp_map() usage, two more items caught my eye:

In qla_mid.c:qla24xx_disable_vp() code:

       ret = qla24xx_control_vp(vha, VCE_COMMAND_DISABLE_VPS_LOGO_ALL);
       atomic_set(&vha->loop_state, LOOP_DOWN);
       atomic_set(&vha->loop_down_timer, LOOP_DOWN_TIME);

       /* Remove port id from vp target map */
       qlt_update_vp_map(vha, RESET_AL_PA);

       qla2x00_mark_vp_devices_dead(vha);
       atomic_set(&vha->vp_state, VP_FAILED);
Quoted 3 lines

AFAICT all callers of qlt_update_vp_map() into qla_target.c code should be holding ->vport_slock. I'll send out a separate patch for this shortly.

Makes sense.

Quoted 20 lines

And in qla_init.c:qla2x00_init_rings() code:

       for (que = 0; que < ha->max_rsp_queues; que++) {
               rsp = ha->rsp_q_map[que];
               if (!rsp)
                       continue;
               /* Initialize response queue entries */
               qla2x00_init_response_q_entries(rsp);
       }

       spin_lock(&ha->vport_slock);

       spin_unlock(&ha->vport_slock);

       ha->tgt.atio_ring_ptr = ha->tgt.atio_ring;
       ha->tgt.atio_ring_index = 0;
       /* Initialize ATIO queue entries */
       qlt_init_atio_q_entries(vha);
Quoted 6 lines

The usage of ->vport_slock seems to be now either unnecessary, or a result of some bad merge outside of qla2xxx target mode.

Qlogic folks, can this (leftover..?) usage of ->vport_slock now be safety removed..?

Yes, this is a left over of code removal and can be safely removed. We already have a patch queued internally for this.

--Arun

This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.