Re: [PATCH 5.10 311/491] dmaengine: xilinx: xilinx_dma: Fix unmasked residue subtraction

Ben Hutchings
2026-04-16T18:43:55Z

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

On Thu, 2026-04-16 at 20:20 +0200, Marek Vasut wrote:
> On 4/16/26 7:58 PM, Ben Hutchings wrote:
> > On Mon, 2026-04-13 at 17:59 +0200, Greg Kroah-Hartman wrote:
> > > 5.10-stable review patch. If anyone has any objections, please let me know.
> > >
> > > ------------------
> > >
> > > From: Marek Vasut <marex@nabladev.com>
> > >
> > > [ Upstream commit c7d812e33f3e8ca0fa9eeabf71d1c7bc3acedc09 ]
> > >
> > > The segment .control and .status fields both contain top bits which are
> > > not part of the buffer size, the buffer size is located only in the bottom
> > > max_buffer_len bits. To avoid interference from those top bits, mask out
> > > the size using max_buffer_len first, and only then subtract the values.
> >
> > This change is harmless, but the problem it claims to fix does not
> > exist.
>
> The current code subtracts two independently read values which both
> contain status/control MSbits and the actual value LSbits. Depending on
> the MSbits being identical in both separately read values is unsafe, so
> the change in this patch masks out the MSbits first and then does the
> subtraction on the actual value LSbits only, which is safe.
>
> Why do you think the original unsafe behavior can not trigger a failure?

The old code masked out the MSbits after subtraction. So, there was no
dependency on their being equal before substraction. Since borrows
propagate to the left, not the right, the MSbits could not "interfere"
with the LSbits.

If you still aren't convinced, please try to find some example values
for which the result would actually change.

Ben.

--
Ben Hutchings
It is easier to change the specification to fit the program
than vice versa.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]