Re: [PATCH v12 05/15] arm64: rqspinlock: Remove private copy of smp_cond_load_acquire_timewait()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removing ARM64's custom `res_smp_cond_load_acquire` before its replacement is available introduces a bisection hole. On systems without an event stream, it causes infinite hangs in WFE, defeating the resilient spinlock's deadlock recovery. On systems with an event stream, it causes massive timeout delays due to inappropriate check amortization.
--

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

arm64: rqspinlock: Remove private copy of smp_cond_load_acquire_timewait()

In preparation for defining smp_cond_load_acquire_timeout(), remove
the private copy. Lacking this, the rqspinlock code falls back to using
smp_cond_load_acquire().

> diff --git a/arch/arm64/include/asm/rqspinlock.h b/arch/arm64/include/asm/rqspinlock.h
> index 9ea0a74e58927..a385603436e98 100644
> --- a/arch/arm64/include/asm/rqspinlock.h
> +++ b/arch/arm64/include/asm/rqspinlock.h
> @@ -3,91 +3,6 @@
>  #define _ASM_RQSPINLOCK_H
>  
>  #include <asm/barrier.h>
[ ... ]
> -#define res_smp_cond_load_acquire(v, c) smp_cond_load_acquire_timewait(v, c, 0, 1)
> -
>  #include <asm-generic/rqspinlock.h>

[Severity: High]
Does removing this macro early introduce a regression during bisection?

If this is removed before the new timeout API is merged, the code will
fallback to using smp_cond_load_acquire() to evaluate the timeout:

kernel/bpf/rqspinlock.c:resilient_queued_spin_lock_slowpath()
    ...
    res_smp_cond_load_acquire(&lock->locked, !VAL || RES_CHECK_TIMEOUT(ts, ret, _Q_LOCKED_MASK));
    ...

On arm64 systems lacking an architectural timer event stream, the wfe
instruction can hang indefinitely if the lock owner is deadlocked and makes
no stores.

Additionally, this fallback activates the default RES_CHECK_TIMEOUT
amortization, which only checks the time after 65,536 loop iterations:

kernel/bpf/rqspinlock.c:RES_CHECK_TIMEOUT
    #ifndef res_smp_cond_load_acquire
    #define RES_CHECK_TIMEOUT(ts, ret, mask)                              \
        ({                                                            \
            if (!(ts).spin++)                                     \
                (ret) = check_timeout((lock), (mask), &(ts)); \

Even with an event stream waking the loop every ~100us, this can delay
deadlock detection by over 6.5 seconds.

It is noted that this regression is fixed later in the series by commit
701dbe31403b3077e33df6fca96fbbc319332c40 ('bpf/rqspinlock: Use
smp_cond_load_acquire_timeout()') and commit
c456c5b49c0e193a118eb1dabfe4657afd8809bb ('bpf/rqspinlock: switch
check_timeout() to a clock interface').

Could this cause bisection holes for anyone testing across this commit?

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