On Mon, Aug 22, 2022 at 1:39 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Aug 22, 2022 at 10:08 AM Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > So why don't we just create a "test_bit_acquire()" and be done with > > it? We literally created clear_bit_unlock() for the opposite reason, > > and your comments about the new barrier hack even point to it. > > Here's a patch that is > > (a) almost entirely untested (I checked that one single case builds > and seems to generate the expected code) > > (b) needs some more loving > > but seems to superficially work. > > At a minimum this needs to be split into two (so the bitop and the > wait_on_bit parts split up), and that whole placement of > <asm/barrier.h> and generic_bit_test_acquire() need at least some > thinking about, but on the whole it seems reasonable. > > For example, it would make more sense to have this in > <asm-generic/bitops/lock.h>, but not all architectures include that, > and some do their own version. I didn't want to mess with > architecture-specific headers, so this illogically just uses > generic-non-atomic.h. > > Maybe just put it in <linux/bitops.h> directly? > > So I'm not at all claiming that this is a great patch. It definitely > needs more work, and a lot more testing. > > But I think this is at least the right _direction_ to take here. > > And yes, I think it also would have been better if > "clear_bit_unlock()" would have been called "clear_bit_release()", and > we'd have more consistent naming with our ordered atomics. But it's > probably not worth changing. Also, as a suggestion to Mikulas or whoever works on this - update the ORDERING section of Documentation/atomic_bitops.txt too? Thanks, - Joel
