On Wed, 2026-10-21 at 13:24 +0100, Gary Guo wrote:
> On Wed Oct 21, 2026 at 1:17 PM BST, Philipp Stanner wrote:
[…]
> > static __always_inline bool test_and_set_bit(long nr, volatile unsigned
> > long *addr)
> > {
> > kcsan_mb();
> > instrument_atomic_read_write(addr + BIT_WORD(nr), sizeof(long));
> > return arch_test_and_set_bit(nr, addr);
> > }
> >
> > Where does the "full ordering" come from? I suppose implied barrier
> > then means it comes from the architecture's implementation. But what's
> > then the purpose of kcsan_XX ?
>
> It's from arch_test_and_set_bit.
>
> KCSAN doesn't see arch code, so the kcsan_mb() and in fact
> instrumnent_atomic_read_write() both are annotations to indicate that this is
> conceptually a mb() + STORE for instrumentation purpose.
We (i.e., someone who's got the overview) could probably document where
and why our atomic instructions are a bit scattered.
Why is test_bit_acquire() defined in include/linux/bitops.h, and should
set_bit_release() be defined there – or here?
P.
