]> rtime.felk.cvut.cz Git - linux-imx.git/commit
[SCSI] qla2xxx: fix potential deadlock on ha->hardware_lock
authorJiri Kosina <jkosina@suse.cz>
Mon, 8 Oct 2012 07:23:54 +0000 (09:23 +0200)
committerJames Bottomley <JBottomley@Parallels.com>
Tue, 9 Oct 2012 11:27:25 +0000 (12:27 +0100)
commitf24b5cb818c6789e5d42d4881f34238a5fa0b40c
tree7806309da7faaff1c867de531a07ce111df0777f
parentbc977749e967daa56de1922cf4cb38525631c51c
[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>
drivers/scsi/qla2xxx/qla_init.c