[PATCH v2 04/14] cxlflash: Avoid command room violation

[Matthew R. Ochs]

Uma,

This looks better, thanks for reworking.


-matt

> On Nov 28, 2016, at 6:41 PM, Uma Krishnan <ukrishn at linux.vnet.ibm.com> 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 at linux.vnet.ibm.com>

Acked-by: Matthew R. Ochs <mrochs at linux.vnet.ibm.com>