Re: [PATCH] ibmvscsi: add write memory barrier to CRQ processing
From: Tyrel Datwyler <hidden>
Date: 2016-12-09 02:56:22
Also in:
linux-scsi
On 12/08/2016 01:06 AM, Johannes Thumshirn wrote:
On Wed, Dec 07, 2016 at 05:31:26PM -0600, Tyrel Datwyler wrote:quoted
The first byte of each CRQ entry is used to indicate whether an entry is a valid response or free for the VIOS to use. After processing a response the driver sets the valid byte to zero to indicate the entry is now free to be reused. Add a memory barrier after this write to ensure no other stores are reordered when updating the valid byte. Signed-off-by: Tyrel Datwyler <redacted> --- drivers/scsi/ibmvscsi/ibmvscsi.c | 2 ++ 1 file changed, 2 insertions(+)diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c index d9534ee..2f5b07e 100644 --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c@@ -232,6 +232,7 @@ static void ibmvscsi_task(void *data) while ((crq = crq_queue_next_crq(&hostdata->queue)) != NULL) { ibmvscsi_handle_crq(crq, hostdata); crq->valid = VIOSRP_CRQ_FREE; + wmb(); } vio_enable_interrupts(vdev);@@ -240,6 +241,7 @@ static void ibmvscsi_task(void *data) vio_disable_interrupts(vdev); ibmvscsi_handle_crq(crq, hostdata); crq->valid = VIOSRP_CRQ_FREE; + wmb(); } else { done = 1; }Is this something you have seen in the wild or just a "better save than sorry" barrier?
I myself have not observed or heard of anybody hitting an issue here. However, based on conversation with the VIOS developers, who have indicated it is required, this is a "better safe than sorry" scenario. Further, it matches what we already do in the ibmvfc driver for the CRQ processing logic. -Tyrel
Thanks, Johannes