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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] dmaengine: plx_dma: missing Fixes trailer in
  plx_dma_process_desc()
--

commit 201d751ec8320e51bb4d2cc4d33f8ffc4f32e196
Author: Logan Gunthorpe <logang@deltatee.com>

> dmaengine: plx_dma: add dma_rmb() after observing write-back status
>
> Completing a descriptor involves two loads that must be ordered:
>
> 1. Reading desc->hw->flags_and_size and checking that VALID is clear.
> 2. Reading the destination buffer, which may happen in:
>    a. dma_unmap_page() via dmaengine_unmap(), when a bounce buffer
>       is in use.
>    b. The client's callback, or its 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 the
> transfer is done. The CPU can predict that the VALID check won't
> break out of the loop and issue load 2 early. If the device hadn't
> finished writing at that moment, load 2 returns stale data, and when
> load 1 then confirms the prediction nothing is redone, so the stale
> data is used. This is the load-load control dependency case described
> in Documentation/memory-barriers.txt.
>
> Add a dma_rmb() after the status check so loads after it can't be
> satisfied before the status read.
>
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Link: https://lore.kernel.org/dmaengine/20260717223217.B6FBF1F000E9@smtp.kernel.org
> Signed-off-by: Logan Gunthorpe <logang@deltatee.com>

[Severity: Low]
Since this fixes an ordering bug in plx_dma_process_desc(), should the
commit message include a Fixes tag?

  Fixes: c2dbcaa8c672 ("dmaengine: plx-dma: Implement hardware initialization and cleanup")

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110173927.624629-1-logang@deltatee.com?part=4