Re: [PATCH v15 06/16] asm-generic: barrier: Add smp_cond_load_acquire_timeout()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Multiple evaluation of the `ptr` macro argument in `smp_cond_load_acquire_timeout` on the timeout path.
--

commit c0f6b64c6c325f3292df62f7c1aed5d22469c935
Author: Ankur Arora <ankur.a.arora@oracle.com>

asm-generic: barrier: Add smp_cond_load_acquire_timeout()

Add the acquire variant of smp_cond_load_relaxed_timeout().

> diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h
> index 8c37de1929443..8b166acfba123 100644
> --- a/include/asm-generic/barrier.h
> +++ b/include/asm-generic/barrier.h

[ ... ]

> +#ifndef smp_cond_load_acquire_timeout
> +#define smp_cond_load_acquire_timeout(ptr, cond_expr,			\
> +				      time_expr_ns, timeout_ns)		\
> +({									\
> +	__unqual_scalar_typeof(*(ptr)) VAL;				\
> +	VAL = smp_cond_load_relaxed_timeout(ptr, cond_expr,		\
> +					     time_expr_ns,		\
> +					     timeout_ns);		\

[ ... ]

> +	if (cond_expr)							\
> +		smp_acquire__after_ctrl_dep();				\
> +	else								\
> +		VAL = smp_load_acquire(ptr);				\

[Severity: Medium]
Could this result in multiple evaluations of the ptr macro argument if the wait
condition times out?

If a caller passes an expression with side effects, such as *ptr++, the side
effect would execute when passed to smp_cond_load_relaxed_timeout, and then a
second time on the timeout path when passed to smp_load_acquire(ptr). This
could potentially lead to incorrect state.

Other macros like smp_cond_load_relaxed explicitly cache ptr in a local __PTR
variable to prevent this issue. Would it be safer to cache ptr here as well?

> +	(typeof(*(ptr)))VAL;						\
> +})
> +#endif

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831202251.305046-1-ankur.a.arora@oracle.com?part=6