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

Uma,

This looks better, thanks for reworking.


-matt

On Nov 28, 2016, at 6:41 PM, Uma Krishnan [off-list ref] =

wrote:

=20
During test, a command room violation interrupt is occasionally seen
for the master context when the CXL flash devices are stressed.
=20
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.
=20
This behavior is incorrect on two counts:
=20
  - The update fails to take into account the current thread and its
    consumption of one of the hardware commands.
=20
  - 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.
=20
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.
=20
Signed-off-by: Uma Krishnan <redacted>

Acked-by: Matthew R. Ochs <redacted>