=================================
[ INFO: inconsistent lock state ]
---------------------------------
inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
(&adapter->erp_lock){+-..}, at: [<000000000026c7f8>] zfcp_erp_async_handler+0x3c/0x70
{hardirq-on-W} state was registered at:
[<000000000005f33e>] __lock_acquire+0x30a/0xed0
[<00000000000604ae>] lock_acquire+0x9a/0xc8
[<000000000035a7ae>] _write_lock+0x4e/0x68
[<000000000026d822>] zfcp_erp_adapter_strategy_generic+0x286/0xd94
[<000000000026fd72>] zfcp_erp_strategy_do_action+0x91e/0x1a94
[<0000000000271a3a>] zfcp_erp_thread+0x21a/0x1568
[<0000000000019096>] kernel_thread_starter+0x6/0xc
[<0000000000019090>] kernel_thread_starter+0x0/0xc
irq event stamp: 12078
hardirqs last enabled at (12077): [<0000000000019416>] cpu_idle+0x206/0x250
hardirqs last disabled at (12078): [<0000000000020458>] io_no_vtime+0xc/0x1c
softirqs last enabled at (12072): [<0000000000040b62>] __do_softirq+0x13a/0x180
softirqs last disabled at (12059): [<000000000001fd58>] do_softirq+0xec/0xf0
other info that might help us debug this:
no locks held by swapper/0.
stack backtrace:
00000000012bb648 0000000000000002 0000000000000000 00000000012bb758
00000000012bb6c0 0000000000399122 0000000000399122 0000000000016b0a
0000000000000000 0000000000000001 0000000000000000 00000000004660e8
0000000000000000 000000000000000d 00000000012bb6b8 00000000012bb730
0000000000368b90 0000000000016b0a 00000000012bb6b8 00000000012bb708
Call Trace:
([<0000000000016a26>] show_trace+0x76/0xdc)
[<0000000000016b2c>] show_stack+0xa0/0xd0
[<0000000000016b8a>] dump_stack+0x2e/0x3c
[<000000000005e3da>] print_usage_bug+0x27e/0x290
[<000000000005e934>] mark_lock+0x548/0x6c0
[<000000000005fb0c>] __lock_acquire+0xad8/0xed0
[<00000000000604ae>] lock_acquire+0x9a/0xc8
[<000000000035a662>] _write_lock_irqsave+0x62/0x80
[<000000000026c7f8>] zfcp_erp_async_handler+0x3c/0x70
[<0000000000279178>] zfcp_fsf_req_dispatch+0xd8/0x1fa8
[<000000000027e538>] zfcp_fsf_req_complete+0x104/0xe4c
[<0000000000274534>] zfcp_qdio_reqid_check+0xf4/0x178
[<000000000027469e>] zfcp_qdio_response_handler+0xe6/0x430
[<0000000000219dd4>] tiqdio_thinint_handler+0xd20/0x213c
[<000000000020229a>] do_adapter_IO+0xb2/0xc0
[<0000000000206f32>] do_IRQ+0x136/0x16c
[<0000000000020462>] io_no_vtime+0x16/0x1c
[<0000000000019432>] cpu_idle+0x222/0x250
([<0000000000019416>] cpu_idle+0x206/0x250)
[<000000000001405a>] rest_init+0x5a/0x68
[<0000000000536998>] start_kernel+0x39c/0x3dc
[<0000000000013046>] _stext+0x46/0x1000
From: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
Fix incorrect usage of erp_lock. Using the write_lock() variant is wrong,
since this might lead to deadlocks.
Acked-by: Andreas Herrmann <aherrman@xxxxxxxxxx>
Signed-off-by: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
---
drivers/s390/scsi/zfcp_erp.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/s390/scsi/zfcp_erp.c b/drivers/s390/scsi/zfcp_erp.c
index 909731b..8ec8da0 100644
--- a/drivers/s390/scsi/zfcp_erp.c
+++ b/drivers/s390/scsi/zfcp_erp.c
@@ -2168,9 +2168,9 @@ zfcp_erp_adapter_strategy_open_fsf_xconf
atomic_clear_mask(ZFCP_STATUS_ADAPTER_HOST_CON_INIT,
&adapter->status);
ZFCP_LOG_DEBUG("Doing exchange config data\n");
- write_lock(&adapter->erp_lock);
+ write_lock_irq(&adapter->erp_lock);
zfcp_erp_action_to_running(erp_action);
- write_unlock(&adapter->erp_lock);
+ write_unlock_irq(&adapter->erp_lock);
zfcp_erp_timeout_init(erp_action);
if (zfcp_fsf_exchange_config_data(erp_action)) {
retval = ZFCP_ERP_FAILED;
@@ -2236,9 +2236,9 @@ zfcp_erp_adapter_strategy_open_fsf_xport
adapter = erp_action->adapter;
atomic_clear_mask(ZFCP_STATUS_ADAPTER_XPORT_OK, &adapter->status);
- write_lock(&adapter->erp_lock);
+ write_lock_irq(&adapter->erp_lock);
zfcp_erp_action_to_running(erp_action);
- write_unlock(&adapter->erp_lock);
+ write_unlock_irq(&adapter->erp_lock);
zfcp_erp_timeout_init(erp_action);
ret = zfcp_fsf_exchange_port_data(erp_action, adapter, NULL);
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
