Re: [PATCH 4/6] dmaengine: plx_dma: add dma_rmb() after observing write-back status

[Logan Gunthorpe <logang@deltatee.com>]

Thanks for the reviews, I've included your tags in the patches I'll send
next week.

On 2026-11-06 10:47, Frank Li wrote:
> On Tue, Nov 03, 2026 at 09:51:59AM -0600, Logan Gunthorpe wrote:
>> +		/*
>> +		 * Ensure the write-back status is read before the
>> +		 * completed transfer's payload.
>> +		 */
>> +		dma_rmb();
>> +
> 
> Is it false alarm by sashiko? follow code have dependence with 'flags'.
> 
> which part in Documentation/memory-barriers.txt show here need dma_rmb()?

Yes, this stuff always confuses me to no end. But I'm pretty sure it is
correct so let me try to explain.

The two actions in question are:

1. read desc->hw->flags_and_size and check if VALID is clear
2. read the destination buffer which may happen in:
   a. dma_unmap_page() via dmaengine_unmap() in the case of a bounce
      buffer being used
   b. a calling driver's callback or processing after polling with
      tx_status()

On a weakly ordered CPU like arm64, nothing forces load 2 to happen
after load 1, even though load 2 is only reached when load 1 says
"done". The CPU predicts that (flags & VALID) condition won't be taken
and issues load 2 early. If the device hadn't finished writing at that
moment, load 2 returns stale data. When load 1 then confirms the
prediction, nothing gets redone, and the stale data is used. That's the
"load-load control dependency" case in memory-barriers.txt. dma_rmb()
stops loads after it from being satisfied before loads ahead of it.

I've tried to improve the comment on the dma_rmb() call to hopefully be
more clear on this point and I'll put the above text as the commit
message seeing I think it is clearer for when I send the series again.

Logan