On Wed, Oct 21, 2026, at 13:54, Gary Guo wrote:
> On Wed Oct 21, 2026 at 12:33 PM BST, Arnd Bergmann wrote:
>> I'm always confused by this and the new function makes it harder
>> to understand in the current form:
...
>> - Contrary to that, the kerneldoc comment over set_bit() mentions
>> "This is a relaxed atomic operation (no implied memory barriers)"
>> and leaves out the kcsan_mb() that is in test_and_set_bit().
>> This makes the new set_bit_release() sound like a /stronger/
>> version of set_bit() the same way that test_bit_acquire()
>> is a stronger version of the (relaxed) test_bit().
>
> set_bit has relaxed semantics while test_and_set_bit implies barrier. RISC-V
> for
> exmaple will generate the amoor instruction for set_bit, not amoor.aqrl.
Thanks for the clarification, I did misread the implementation
and see how I was confused once more.
Arnd
