From: NeilBrown <neilb@suse.de>
To: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: [PATCH 0/9 RFC] Make wake_up_{bit,var} less fragile
Date: Mon, 19 Aug 2024 15:20:34 +1000 [thread overview]
Message-ID: <20240819053605.11706-1-neilb@suse.de> (raw)
I wasn't really sure who to send this too, and get_maintainer.pl
suggested 132 addresses which seemed excessive. So I've focussed on
'sched' maintainers. I'll probably submit individual patches to
relevant maintainers/lists if I get positive feedback at this level.
This series was motivated by
Commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task")
which adds smp_mb__after_atomic(). I thought "any API that requires that
sort of thing needs to be fixed".
The main patches here are 7 and 8 which revise wake_up_bit and
wake_up_var respectively. They result in 3 interfaces:
wake_up_{bit,var} includes smp_mb__after_atomic()
wake_up_{bit,var}_relaxed() doesn't have a barrier
wake_up_{bit,var}_mb() includes smb_mb().
I think this set of interfaces should be easier to use correctly. They
are also now documented more clearly.
The preceeding patches clean up various places where the exiting
interfaces weren't used optimally. The final patch uses
clear_and_wake_up_bit() more widely because it seems like a good idea.
I have three questions:
1/ is my understanding of the needed barriers correct.
i.e:
smp_mb__after_atomic() needed after a clear_bit() to atomic_set()
or similar, or a change inside a locked region
smb_mb() needed after any non-locked update
nothing needed after test_and_clear_bit() or atomic_dec_and_test()
or similar.
(I realised while working on this that my previous understanding
of the barrier requires was wrong, so maybe it still is).
2/ How should we handle the "flag day" where a barrier is added to
wake_up_bit() and wake_up_var(). Some options are:
a/ have a big patch for the flag-day as this series does
b/ add the barrier in a new wake_up_atomic_{bit,var} and deprecate
wake_up_{bit,var}
c/ don't worry about the fact that there will be an extra barrier for
a while - just make the change to wake_up_xxx() first, then submit
individual patches to remove barriers as needed.
3/ Who else should I ask to remove this at this high level?
Thanks,
NeilBrown
[PATCH 1/9] i915: remove wake_up on I915_RESET_MODESET.
[PATCH 2/9] Introduce atomic_dec_and_wake_up_var().
[PATCH 3/9] XFS: use wait_var_event() when waiting of i_pincount.
[PATCH 4/9] Use wait_var_event() instead of I_DIO_WAKEUP
[PATCH 5/9] Block: switch bd_prepare_to_claim to use
[PATCH 6/9] block/pktdvd: switch congestion waiting to
[PATCH 7/9] Improve and expand wake_up_bit() interface.
[PATCH 8/9] Improve and extend wake_up_var() interface.
[PATCH 9/9] Use clear_and_wake_up_bit() where appropriate.
next reply other threads:[~2024-08-19 5:36 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-19 5:20 NeilBrown [this message]
2024-08-19 5:20 ` [PATCH 1/9] i915: remove wake_up on I915_RESET_MODESET NeilBrown
2024-08-19 5:20 ` [PATCH 2/9] Introduce atomic_dec_and_wake_up_var() NeilBrown
2024-08-20 5:47 ` kernel test robot
2024-08-21 5:23 ` kernel test robot
2024-08-19 5:20 ` [PATCH 3/9] XFS: use wait_var_event() when waiting of i_pincount NeilBrown
2024-08-19 5:20 ` [PATCH 4/9] Use wait_var_event() instead of I_DIO_WAKEUP NeilBrown
2024-08-20 7:22 ` Christian Brauner
2024-08-20 19:12 ` Christian Brauner
2024-08-19 5:20 ` [PATCH 5/9] Block: switch bd_prepare_to_claim to use ___wait_var_event() NeilBrown
2024-08-20 4:18 ` Dave Chinner
2024-08-20 21:52 ` NeilBrown
2024-08-28 1:22 ` Dave Chinner
2024-08-28 5:20 ` NeilBrown
2024-08-21 7:10 ` kernel test robot
2024-08-19 5:20 ` [PATCH 6/9] block/pktdvd: switch congestion waiting to ___wait_var_event() NeilBrown
2024-08-19 5:20 ` [PATCH 7/9] Improve and expand wake_up_bit() interface NeilBrown
2024-08-19 5:20 ` [PATCH 8/9] Improve and extend wake_up_var() interface NeilBrown
2024-08-19 5:20 ` [PATCH 9/9] Use clear_and_wake_up_bit() where appropriate NeilBrown
2024-08-19 6:13 ` [PATCH 0/9 RFC] Make wake_up_{bit,var} less fragile Linus Torvalds
2024-08-20 21:47 ` NeilBrown
2024-08-20 21:58 ` Linus Torvalds
2024-08-20 22:15 ` NeilBrown
2024-08-20 22:24 ` Linus Torvalds
2024-08-19 8:16 ` Christian Brauner
2024-08-19 17:45 ` Linus Torvalds
2024-08-19 20:52 ` NeilBrown
2024-08-19 21:12 ` Linus Torvalds
2024-08-20 16:06 ` [PATCH RFC 0/5] inode: turn i_state into u32 Christian Brauner
2024-08-20 16:06 ` [PATCH RFC 1/5] fs: add i_state helpers Christian Brauner
2024-08-20 17:10 ` Linus Torvalds
2024-08-20 17:19 ` Linus Torvalds
2024-08-20 19:10 ` Christian Brauner
2024-08-20 19:08 ` Christian Brauner
2024-08-20 16:06 ` [PATCH RFC 2/5] writeback: port __I_SYNC to var event Christian Brauner
2024-08-20 16:06 ` [PATCH RFC 3/5] inode: port __I_NEW " Christian Brauner
2024-08-20 16:06 ` [PATCH RFC 4/5] inode: port __I_LRU_ISOLATING " Christian Brauner
2024-08-20 16:06 ` [PATCH RFC 5/5] inode: make i_state a u32 Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240819053605.11706-1-neilb@suse.de \
--to=neilb@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox