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@gmail.com>
Closes: https://lore.kernel.org/loongarch/CAK3+h2xOSEZUHhou7N2cRL-aGrZCNSm45g+P7thObMe+fpgYCA@mail.gmail.com/
Fixes: 46859ac8af52 ("LoongArch: Add multi-processor (SMP) support")
Cc: stable@vger.kernel.org
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 arch/loongarch/include/asm/barrier.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/loongarch/include/asm/barrier.h b/arch/loongarch/include/asm/barrier.h
index 4b663f197706..84c6d739119d 100644
--- a/arch/loongarch/include/asm/barrier.h
+++ b/arch/loongarch/include/asm/barrier.h
@@ -57,9 +57,6 @@
 #define __WEAK_LLSC_MB		"			\n"
 #endif
 
-#define __smp_mb__before_atomic()	barrier()
-#define __smp_mb__after_atomic()	barrier()
-
 /**
  * array_index_mask_nospec() - generate a ~0 mask when index < size, 0 otherwise
  * @index: array element index
-- 
2.42.0

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@gmail.com>
> Closes: https://lore.kernel.org/loongarch/CAK3+h2xOSEZUHhou7N2cRL-aGrZCNSm45g+P7thObMe+fpgYCA@mail.gmail.com/
> Fixes: 46859ac8af52 ("LoongArch: Add multi-processor (SMP) support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

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@xry111.site>

-- 
Xi Ruoyao <xry111@xry111.site>