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>
struct lpfc_sli4_hdw_queue *qp;
int idx;
- spin_lock_irq(&phba->hbalock);
-
for (idx = 0; idx < phba->cfg_hdw_queue; idx++) {
qp = &phba->sli4_hba.hdwq[idx];
/* Release all the lpfc_nvme_bufs maintained by this host. */
}
spin_unlock(&qp->io_buf_list_get_lock);
}
-
- spin_unlock_irq(&phba->hbalock);
}
/**