From: NeilBrown <neilb@suse.de>
To: Trond Myklebust <trondmy@kernel.org>, Anna Schumaker <anna@kernel.org>
Cc: linux-nfs@vger.kernel.org
Subject: [PATCH 00/11] nfs: improve use of wake_up_bit and wake_up_var
Date: Fri, 6 Dec 2024 13:15:26 +1100 [thread overview]
Message-ID: <20241206021830.3526922-1-neilb@suse.de> (raw)
wake_up_bit and wake_up_var are fragile interfaces as they sometimes
require a barrier before them. Recently some new interfaces were added
which avoid the need for explicit barriers. If we can remove all
instances of those fragile interfaces, that would be ideal.
Unforunately there is one can in NFS that does not fit the new
interfaces. However most do. This series replaces most use of the old
interfaces with the new, and adds various related cleanups.
Thanks,
NeilBrown
next reply other threads:[~2024-12-06 2:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-06 2:15 NeilBrown [this message]
2024-12-06 2:15 ` [PATCH 01/11] sunrpc: remove explicit barrier from rpc_make_runnable() NeilBrown
2024-12-06 2:15 ` [PATCH 02/11] sunrpc: use clear_and_wake_up_bit() for XPRT_LOCKED NeilBrown
2024-12-06 2:15 ` [PATCH 03/11] nfs: use clear_and_wake_up_bit() NeilBrown
2024-12-06 2:15 ` [PATCH 04/11] nfs: combine NFS_LAYOUT_RETURN and NFS_LAYOUT_RETURN_LOCK NeilBrown
2025-01-22 20:45 ` Mike Snitzer
2025-01-22 21:25 ` NeilBrown
2024-12-06 2:15 ` [PATCH 05/11] nfs: use clear_and_wake_up_bit() in pnfs code NeilBrown
2024-12-06 2:15 ` [PATCH 06/11] nfs: use store_release_wake_up() for clearing d_fsdata NeilBrown
2024-12-06 2:15 ` [PATCH 07/11] sunrpc: discard rpc_wait_bit_killable() NeilBrown
2024-12-06 2:15 ` [PATCH 08/11] nfs: discard nfs_wait_bit_killable() NeilBrown
2024-12-06 2:15 ` [PATCH 09/11] nfs: add memory barrier before calling wake_up_var on cl_state NeilBrown
2024-12-06 2:15 ` [PATCH 10/11] nfs: use atomic_dec_and_wake_up() NeilBrown
2024-12-06 2:15 ` [PATCH 11/11] nfs: use wait_var_event_spinlock() to wait for nfsi->layout to change NeilBrown
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=20241206021830.3526922-1-neilb@suse.de \
--to=neilb@suse.de \
--cc=anna@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@kernel.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