Re: [PATCH v15 07/16] atomic: Add atomic_cond_read_*_timeout()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] `atomic64_cond_read_*_timeout` uses non-atomic torn reads on 32-bit platforms.
--

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

atomic: Add atomic_cond_read_*_timeout()

This commit adds atomic load wrappers, atomic_cond_read_*_timeout() and
atomic64_cond_read_*_timeout() for the cond-load timeout interfaces. It also
adds a short description for the atomic_cond_read_{relaxed,acquire}(), and
the atomic_cond_read_{relaxed,acquire}_timeout() interfaces.

> diff --git a/include/linux/atomic.h b/include/linux/atomic.h
> index 8dd57c3a99e9b..5bcb86e077845 100644
> --- a/include/linux/atomic.h
> +++ b/include/linux/atomic.h
[ ... ]
> @@ -31,6 +31,16 @@
>  #define atomic64_cond_read_acquire(v, c) smp_cond_load_acquire(&(v)->counter, (c))
>  #define atomic64_cond_read_relaxed(v, c) smp_cond_load_relaxed(&(v)->counter, (c))
>  
> +#define atomic_cond_read_acquire_timeout(v, c, e, t) \
> +	smp_cond_load_acquire_timeout(&(v)->counter, (c), (e), (t))
> +#define atomic_cond_read_relaxed_timeout(v, c, e, t) \
> +	smp_cond_load_relaxed_timeout(&(v)->counter, (c), (e), (t))
> +
> +#define atomic64_cond_read_acquire_timeout(v, c, e, t) \
> +	smp_cond_load_acquire_timeout(&(v)->counter, (c), (e), (t))

[Severity: High]
This is a pre-existing issue, but does this code result in non-atomic torn
reads on 32-bit platforms?

When a caller uses atomic64_cond_read_acquire_timeout() or
atomic64_cond_read_relaxed_timeout() on a 32-bit architecture using
CONFIG_GENERIC_ATOMIC64, smp_cond_load_* executes a lockless
READ_ONCE(&(v)->counter). This causes the compiler to emit two 32-bit loads.

If generic_atomic64_add() or an interrupt handler modifies the value under a
spinlock concurrently, the read can tear. Evaluating loop conditions against
this corrupted memory could lead to spurious wakeups and returning torn,
inconsistent 64-bit values to the caller, silently breaking synchronization
logic.

The patch replicates this pre-existing flaw from atomic64_cond_read_acquire()
into the new timeout variants rather than utilizing the lock-protected
atomic64_read().

> +#define atomic64_cond_read_relaxed_timeout(v, c, e, t) \
> +	smp_cond_load_relaxed_timeout(&(v)->counter, (c), (e), (t))

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