linux-kernel - Re: [PATCH v8 04/12] arm64: support WFET in smp_cond_relaxed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aWEOALG07jHC_oHC@willie-the-truck>
Date: Fri, 9 Jan 2026 14:17:36 +0000
From: Will Deacon <will@...nel.org>
To: Ankur Arora <ankur.a.arora@...cle.com>
Cc: linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-pm@...r.kernel.org,
	bpf@...r.kernel.org, arnd@...db.de, catalin.marinas@....com,
	peterz@...radead.org, akpm@...ux-foundation.org,
	mark.rutland@....com, harisokn@...zon.com, cl@...two.org,
	ast@...nel.org, rafael@...nel.org, daniel.lezcano@...aro.org,
	memxor@...il.com, zhenglifeng1@...wei.com,
	xueshuai@...ux.alibaba.com, joao.m.martins@...cle.com,
	boris.ostrovsky@...cle.com, konrad.wilk@...cle.com
Subject: Re: [PATCH v8 04/12] arm64: support WFET in
 smp_cond_relaxed_timeout()

On Sun, Dec 14, 2025 at 08:49:11PM -0800, Ankur Arora wrote:
> Extend __cmpwait_relaxed() to __cmpwait_relaxed_timeout() which takes
> an additional timeout value in ns.
> 
> Lacking WFET, or with zero or negative value of timeout we fallback
> to WFE.
> 
> Cc: Arnd Bergmann <arnd@...db.de>
> Cc: Catalin Marinas <catalin.marinas@....com>
> Cc: Will Deacon <will@...nel.org>
> Cc: linux-arm-kernel@...ts.infradead.org
> Signed-off-by: Ankur Arora <ankur.a.arora@...cle.com>
> ---
>  arch/arm64/include/asm/barrier.h |  8 ++--
>  arch/arm64/include/asm/cmpxchg.h | 72 ++++++++++++++++++++++----------
>  2 files changed, 55 insertions(+), 25 deletions(-)

Sorry, just spotted something else on this...

> diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
> index 6190e178db51..fbd71cd4ef4e 100644
> --- a/arch/arm64/include/asm/barrier.h
> +++ b/arch/arm64/include/asm/barrier.h
> @@ -224,8 +224,8 @@ do {									\
>  extern bool arch_timer_evtstrm_available(void);
>  
>  /*
> - * In the common case, cpu_poll_relax() sits waiting in __cmpwait_relaxed()
> - * for the ptr value to change.
> + * In the common case, cpu_poll_relax() sits waiting in __cmpwait_relaxed()/
> + * __cmpwait_relaxed_timeout() for the ptr value to change.
>   *
>   * Since this period is reasonably long, choose SMP_TIMEOUT_POLL_COUNT
>   * to be 1, so smp_cond_load_{relaxed,acquire}_timeout() does a
> @@ -234,7 +234,9 @@ extern bool arch_timer_evtstrm_available(void);
>  #define SMP_TIMEOUT_POLL_COUNT	1
>  
>  #define cpu_poll_relax(ptr, val, timeout_ns) do {			\
> -	if (arch_timer_evtstrm_available())				\
> +	if (alternative_has_cap_unlikely(ARM64_HAS_WFXT))		\
> +		__cmpwait_relaxed_timeout(ptr, val, timeout_ns);	\
> +	else if (arch_timer_evtstrm_available())			\
>  		__cmpwait_relaxed(ptr, val);				\

Don't you want to make sure that we have the event stream available for
__cmpwait_relaxed_timeout() too? Otherwise, a large timeout is going to
cause problems.

Will