Re: [PATCH] x86/atomic: Fix UB on various atomic helpers

[Jan Beulich <jbeulich@xxxxxxxx>]

On 14.10.2026 15:35, Alejandro Vallejo wrote:
> --- a/xen/arch/x86/include/asm/atomic.h
> +++ b/xen/arch/x86/include/asm/atomic.h
> @@ -122,7 +122,7 @@ static inline void atomic_add(int i, atomic_t *v)
>  
>  static inline int atomic_add_return(int i, atomic_t *v)
>  {
> -    return i + arch_fetch_and_add(&v->counter, i);
> +    return (unsigned int)i + arch_fetch_and_add(&v->counter, i);
>  }

I'm concerned seeing this kind of change: It's merely papering over an
issue in the caller. There's not going to be UB if the caller passes
suitable values. And the atomic types hardly are meant to be used in
contexts where overflow could occur.

Furthermore different parts of the C spec say different things here [1],
[2]. Hence whether overflow in signed calculations is undefined or
implementation-defined doesn't become entirely clear, according to my
reading.

Yes, [2] is from "Conversions" when here we talk about expression
results, but unsigned overflow not being UB also only follows from
what's said under "Conversions".

Jan

[1] From "Expressions":

"If an exceptional condition occurs during the evaluation of an expression
 (that is, if the result is not mathematically defined or not in the range
 of representable values for its type), the behavior is undefined."

[2] From "Conversions" / "Arithmetic operands" / "Signed and unsigned
    Integers":

"Otherwise, the new type is signed and the value cannot be represented in
 it; either the result is implementation-defined or an implementation-
 defined signal is raised."