scsi: lpfc: Resolve irq-unsafe lockdep heirarchy warning in lpfc_io_free

scsi: lpfc: Resolve irq-unsafe lockdep heirarchy warning in lpfc_io_free

[ Upstream commit 50e3f871fb20a9bb644743e2986e8f50f98a25bc ]

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>
Signed-off-by: Sasha Levin <sashal@kernel.org>