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

Marek Vasut
2026-04-18T16:51:09Z

On 4/16/26 8:43 PM, Ben Hutchings wrote:
> 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.
Ah sigh, you're right. I will add this into the list of lessons learnt
the hard way. Thank you for the clarification.