On Thu, 22 Aug 2024, Dave Chinner wrote:
>
> Even better would be to fix wake_up_var() to not have an implicit
> ordering requirement. Add __wake_up_var() as the "I know what I'm
> doing" API, and have wake_up_var() always issue the memory barrier
> like so:
>
> __wake_up_var(var)
> {
> __wake_up_bit(....);
> }
>
> wake_up_var(var)
> {
> smp_mb();
> __wake_up_var(var);
> }
This is very close to what I proposed
https://lore.kernel.org/all/20240819053605.11706-9-neilb@xxxxxxx/
but Linus doesn't like that approach.
I would prefer a collection of interfaces which combine the update to
the variable with the wake_up.
So
atomic_dec_and_wake()
store_release_and_wake()
though there are a few that don't fit into a common pattern.
Sometimes a minor code re-write can make them fit. Other times I'm not
so sure.
I'm glad I'm not the only one who though that adding a barrier to
wake_up_var() was a good idea though - thanks.
NeilBrown
>
> Then people who don't intimately understand ordering (i.e. just want
> to use a conditional wait variable) or just don't want to
> think about complex memory ordering issues for otherwise obvious and
> simple code can simply use the safe variant.
>
> Those that need to optimise for speed or know they have solid
> ordering or external serialisation can use __wake_up_var() and leave
> a comment as to why that is safe. i.e.:
>
> /*
> * No wait/wakeup ordering required as both waker and waiters
> * are serialised by the inode->i_lock.
> */
> __wake_up_var(....);
>
> -Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
>
