Re: [PATCH 4/9] hw/dma/omap_dma: Be more careful about overflow in transfer setup

[Jim MacArthur <jim.macarthur@linaro.org>]

On Fri, Jul 10, 2026 at 11:59:02AM +0100, Peter Maydell wrote:
> In omap_dma_transfer_setup(), the maximum number of elements we can
> transfer is 0xffff * 0xffff == 0xfffe0001 (because the max frame
> count and max elements per frame are both 65535).  However, we store
> total element counts in 'int' variables, and use INT_MAX as a "bigger
> than any valid value" sentinel, and when performing arithmetic with
> the total count of transferred elements we are not careful about
> avoiding overflows. Fix these:
> 
>  - use uint32_t rather than int for the local variables tracking
>    various element and frame counts
>  - use UINT_MAX as our sentinel
>  - calculate new packet, element and frame counter values using
>    arithmetic on a local uint32_t, rather than doing it in-place
>    on local variables that are only 'int' because the actual
>    counter registers are 16 bits
>  - use 64-bit arithmetic when calculating how much to advance the
>    source and dest pointers and the total dma->bytes transferred
> 
> Note that since soc_dma_ch_s::bytes is only 'int' this can still
> overflow; we'll fix that in a subsequent patch.
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

LGTM, thanks Peter.

Reviewed-by: Jim MacArthur <jim.macarthur@linaro.org>