scsi: cxlflash: Avoid command room violation
authorUma Krishnan <ukrishn@linux.vnet.ibm.com>
Tue, 29 Nov 2016 00:41:45 +0000 (18:41 -0600)
committerMartin K. Petersen <martin.petersen@oracle.com>
Wed, 30 Nov 2016 16:34:01 +0000 (11:34 -0500)
commit11f7b1844ac01d0298aad6a0ec2591bef4a1c3a2
tree79813986a17a475e90e13766d8c6d5c4b9e72466
parent3d2f617d448f5e1d15d2844b803c13763ed51f1f
scsi: cxlflash: Avoid command room violation

During test, a command room violation interrupt is occasionally seen
for the master context when the CXL flash devices are stressed.

After studying the code, there could be gaps in the way command room
value is being cached in cxlflash. When the cached command room is zero
the thread attempting to send becomes burdened with updating the cached
value with the actual value from the AFU. Today, this is handled with an
atomic set operation of the raw value read. Following the atomic update,
the thread proceeds to send.

This behavior is incorrect on two counts:

   - The update fails to take into account the current thread and its
     consumption of one of the hardware commands.

   - The update does not take into account other threads also atomically
     updating. Per design, a worker thread updates the cached value when a
     send thread times out. By not protecting the update with a lock, the
     cached value can be incorrectly clobbered.

To correct these issues, the update of the cached command room has been
simplified and also protected using a spin lock which is held until the
MMIO is complete. This ensures the command room is properly consumed by
the same thread. Update of cached value also takes into account the
current thread consuming a hardware command.

Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
drivers/scsi/cxlflash/common.h
drivers/scsi/cxlflash/main.c