Re: [PATCH v14 04/15] arm64: support WFET in smp_cond_load_relaxed_timeout()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Using `NSECS_TO_CYCLES()` for large macroscopic timeouts causes a 64-bit integer overflow, resulting in a premature return and a CPU-burning spin loop.
- [Low] Any loadable kernel module using `smp_cond_load_relaxed_timeout()` will fail to link due to the unexported symbol `__delay_cycles()`.
--

--- Patch [4]: [PATCH v14 04/15] arm64: support WFET in smp_cond_load_relaxed_timeout() ---
commit 7ff3bc2dcc6f4fa787700453b8fc2f2fe6133304
Author: Ankur Arora <ankur.a.arora@oracle.com>

arm64: support WFET in smp_cond_load_relaxed_timeout()

This commit introduces support for the WFET instruction in 
smp_cond_load_relaxed_timeout(). It adds __cmpwait_timeout() and related
architecture-specific macros to handle the wait state with a timeout.

> diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
> index 6cf3cd6873f5f..9e4cdc9e41d1b 100644
> --- a/arch/arm64/include/asm/cmpxchg.h
> +++ b/arch/arm64/include/asm/cmpxchg.h
[ ... ]
> @@ -235,20 +237,52 @@ __CMPWAIT_CASE( ,  , 64);
>  
>  #undef __CMPWAIT_CASE
>  
> -#define __CMPWAIT_GEN(sfx)						\
> -static __always_inline void __cmpwait##sfx(volatile void *ptr,		\
> -				  unsigned long val,			\
> -				  int size)				\
> +#define __CMPWAIT_TIMEOUT_CASE(w, sfx, sz)				\
> +static inline void __cmpwait_case_timeout_##sz(volatile void *ptr,	\
> +					       unsigned long val,	\
> +					       u64 timeout_ns)		\
> +{									\
> +	unsigned long tmp;						\
> +	u64 ecycles = __delay_cycles() +				\
> +			NSECS_TO_CYCLES(timeout_ns);			\

[Severity: Low]
Will loadable kernel modules fail to link if they use 
smp_cond_load_relaxed_timeout()? 

It appears __delay_cycles() is not exported to modules, which might cause 
an undefined symbol error during the modpost build stage.

[Severity: Medium]
Can NSECS_TO_CYCLES() overflow if passed a large macroscopic timeout? 

Because its internal fixed-point arithmetic caps at 32 bits, passing a 
large timeout (e.g., > 4.29 seconds on a 1GHz timer) might overflow and 
produce a small truncated cycle count. 

Could this cause the WFET instruction to complete prematurely and degrade 
the wait into a CPU-burning loop, leading to a performance regression?

> +	asm volatile(							\
> +	"	sevl\n"							\
> +	"	wfe\n"							\
[ ... ]

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