diff options
author | Jiri Kosina <jkosina@suse.cz> | 2012-10-08 09:23:54 +0200 |
---|---|---|
committer | James Bottomley <JBottomley@Parallels.com> | 2012-10-09 12:27:25 +0100 |
commit | f24b5cb818c6789e5d42d4881f34238a5fa0b40c (patch) | |
tree | 7806309da7faaff1c867de531a07ce111df0777f /include/linux/mfd/tps65910.h | |
parent | bc977749e967daa56de1922cf4cb38525631c51c (diff) |
[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.
Reported-and-tested-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Acked-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Diffstat (limited to 'include/linux/mfd/tps65910.h')
0 files changed, 0 insertions, 0 deletions