Re: [PATCH v2] LoongArch: Remove arch-specific __smp_mb__{before,after}_atomic()

[Xi Ruoyao]

On Tue, 2026-09-08 at 15:39 +0800, Tiezhu Yang wrote:
> When running the BPF selftest "test_progs -t timer_lockup" on a LoongArch
> machine, the kernel intermittently experiences soft lockups and panics in
> hrtimer_cancel().
> 
> The root cause is that bpf_timer_cancel() relies on smp_mb__after_atomic()
> to provide a full data barrier after a relaxed atomic_inc() to ensure the
> proper store-load ordering before performing lockless dependency checks on
> weakly-ordered architectures such as LoongArch, but the current definition
> of smp_mb__after_atomic() is a plain compiler barrier.
> 
> This allows a subsequent read to bypass the prior write due to store-load
> reordering, enabling concurrent CPUs to simultaneously bypass the software
> deadlock detection, enter hrtimer_cancel(), and then trigger a severe ABBA
> deadlock in the hrtimer core.
> 
> Moreover, there are hundreds of smp_mb__after_atomic() call sites across
> the core kernel (kernel/, drivers/, mm/, net/, fs/) that currently lack
> necessary full data barriers on LoongArch, which have potential risks.
> 
> To comply with the LKMM specification, fix this by removing the incorrect
> arch-specific definition of __smp_mb__after_atomic(), so that this macro
> can automatically fall back to the generic definition in asm-generic that
> maps to __smp_mb() and emits the required hardware DBAR instruction. While
> at it, do the same thing for __smp_mb__before_atomic().
> 
> With this patch, the BPF timer_lockup selftest was stressed for 1 million
> consecutive loops on a physical LoongArch machine without encountering any
> further lockups.
> 
> Reported-by: Vincent Li <vincent.mc.li@xxxxxxxxx>
> Closes: https://lore.kernel.org/loongarch/CAK3+h2xOSEZUHhou7N2cRL-aGrZCNSm45g+P7thObMe+fpgYCA@xxxxxxxxxxxxxx/
> Fixes: 46859ac8af52 ("LoongArch: Add multi-processor (SMP) support")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Tiezhu Yang <yangtiezhu@xxxxxxxxxxx>

The Documentation/atomic_t.txt file says:

   These helper barriers exist because architectures have varying implicit
   ordering on their SMP atomic primitives. For example our TSO architectures
   provide full ordered atomics and these barriers are no-ops.

So yes, a compiler barrier cannot be enough.  If I read that file
correctly smp_mb__{before,after}_atomic can only be more permissive than
smp_mb because they allow some accesses *not* against the atomic itself
to pass through, unfortunately LoongArch does not provide such a
"address-aware barrier" so there seems nothing we can do better than a
full barrier.

Reviewed-by: Xi Ruoyao <xry111@xxxxxxxxxxx>

-- 
Xi Ruoyao <xry111@xxxxxxxxxxx>