summaryrefslogtreecommitdiffstats
path: root/drivers/tc
diff options
context:
space:
mode:
authorJames Smart <jsmart2021@gmail.com>2019-09-21 20:58:53 -0700
committerMartin K. Petersen <martin.petersen@oracle.com>2019-09-30 22:07:09 -0400
commit07b8582430370097238b589f4e24da7613ca6dd3 (patch)
treeefac97cbdd74cb49cc1ba965cbc2427b00b0a6a9 /drivers/tc
parent0f154226d699fefe651ccc4db773efc05a820b56 (diff)
downloadlinux-07b8582430370097238b589f4e24da7613ca6dd3.tar.gz
linux-07b8582430370097238b589f4e24da7613ca6dd3.tar.bz2
linux-07b8582430370097238b589f4e24da7613ca6dd3.zip
scsi: lpfc: Fix locking on mailbox command completion
Symptoms were seen of the driver not having valid data for mailbox commands. After debugging, the following sequence was found: The driver maintains a port-wide pointer of the mailbox command that is currently in execution. Once finished, the port-wide pointer is cleared (done in lpfc_sli4_mq_release()). The next mailbox command issued will set the next pointer and so on. The mailbox response data is only copied if there is a valid port-wide pointer. In the failing case, it was seen that a new mailbox command was being attempted in parallel with the completion. The parallel path was seeing the mailbox no long in use (flag check under lock) and thus set the port pointer. The completion path had cleared the active flag under lock, but had not touched the port pointer. The port pointer is cleared after the lock is released. In this case, the completion path cleared the just-set value by the parallel path. Fix by making the calls that clear mbox state/port pointer while under lock. Also slightly cleaned up the error path. Link: https://lore.kernel.org/r/20190922035906.10977-8-jsmart2021@gmail.com 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>
Diffstat (limited to 'drivers/tc')
0 files changed, 0 insertions, 0 deletions