Uma, This looks better, thanks for reworking. -matt > On Nov 28, 2016, at 6:41 PM, Uma Krishnan <ukrishn@xxxxxxxxxxxxxxxxxx> wrote: > > 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@xxxxxxxxxxxxxxxxxx> Acked-by: Matthew R. Ochs <mrochs@xxxxxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html