On Wed, Apr 15, 2026 at 04:28:40PM +0200, Aleksandr Loktionov wrote:
> ixgbe_update_itr() packs a mode flag (IXGBE_ITR_ADAPTIVE_LATENCY,
> bit 7) and a usecs delay (bits [6:0]) into an unsigned int, then
> stores the combined value in ring_container->itr which is declared as
> u8. Values above 0xFF wrap on truncation, corrupting both the delay
> and the mode flag on the next readback.
>
> Keep the mode bit (IXGBE_ITR_ADAPTIVE_LATENCY) and the usec delay as
> separate operands in the final store expression. Clamp only the usecs
> portion to [IXGBE_ITR_ADAPTIVE_MIN_USECS, IXGBE_ITR_ADAPTIVE_MAX_USECS]
> using clamp_val() so that:
> - overflow cannot bleed into the mode bit (bit 7),
> - the delay cannot exceed 126 us (IXGBE_ITR_ADAPTIVE_MAX_USECS),
> - the delay cannot drop below 10 us (IXGBE_ITR_ADAPTIVE_MIN_USECS).
>
> Fixes: b4ded8327fea ("ixgbe: Update adaptive ITR algorithm")
> Cc: [email protected]
> Signed-off-by: Aleksandr Loktionov <[email protected]>
> ---
> v2 -> v3:
> - Use clamp_val() instead of min_t() to also guard the lower bound
> (IXGBE_ITR_ADAPTIVE_MIN_USECS); keep mode and delay as separate
> operands until final store; use IXGBE_ITR_ADAPTIVE_MAX_USECS (126)
> as upper bound instead of IXGBE_ITR_ADAPTIVE_LATENCY - 1 (127)
> (Simon Horman).
FTR: I think the code would be easier to reason with if
mode and delay were kept separate during earlier calculation
of itr. But I also think that can be handled as a follow-up.
as this patch does improve things.
Reviewed-by: Simon Horman <[email protected]>
