scsi: lpfc: Resolve irq-unsafe lockdep heirarchy warning in lpfc_io_free
authorJames Smart <jsmart2021@gmail.com>
Tue, 12 Mar 2019 23:30:05 +0000 (16:30 -0700)
committerMartin K. Petersen <martin.petersen@oracle.com>
Tue, 19 Mar 2019 16:57:01 +0000 (12:57 -0400)
commit50e3f871fb20a9bb644743e2986e8f50f98a25bc
treecde54d9f106c3baaa97c2e60a48e6daa6334fb9f
parentff6bf89717b0dc7b8dd0934d1c065f29069831e7
scsi: lpfc: Resolve irq-unsafe lockdep heirarchy warning in lpfc_io_free

A patch in the 12.2.0.0 set caused a new lockdep warning:

  WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
  5.0.0-rc8-next-20190301-dbg+ #1 Not tainted

  Possible interrupt unsafe locking scenario:
       CPU0                    CPU1
       ----                    ----
  lock(&(&qp->io_buf_list_put_lock)->rlock);
                               local_irq_disable();
                               lock(&(&phba->hbalock)->rlock);
                               lock(&(&qp->io_buf_list_put_lock)->rlock);
  <Interrupt>
    lock(&(&phba->hbalock)->rlock);

see: https://www.spinics.net/lists/linux-scsi/msg128389.html

In summary, the new patch added taking the io_buf_list_put_lock while under
an irq-disabled hbalock. This created a lock heirarchy dependent upon irq
being disabled, and there are paths that take the io_buf_list_put_lock
without disabling irq.

Looking at the lpfc_io_free routine, which is where the new heirarchy was
introduced, there is no reason to be taking out the hbalock and raising
irq, as the functionality is replaced by the io_buf_list_xxx locks.

Resolve by removing the hbalock/irq calls in lpfc_io_free.

Fixes: 5e5b511d8bfa ("scsi: lpfc: Partition XRI buffer list across Hardware Queues")
Reported-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
drivers/scsi/lpfc/lpfc_init.c