From: Kent Overstreet <kent.overstreet@linux.dev>
To: linux-bcache@vger.kernel.org, linux-bcachefs@vger.kernel.org
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Subject: [PATCH 1/2] closures: Better memory barriers
Date: Tue, 31 Oct 2023 12:24:51 -0400 [thread overview]
Message-ID: <20231031162454.3761482-2-kent.overstreet@linux.dev> (raw)
In-Reply-To: <20231031162454.3761482-1-kent.overstreet@linux.dev>
atomic_(dec|sub)_return_release() are a thing now - use them.
Also, delete the useless barrier in set_closure_fn(): it's redundant
with the memory barrier in closure_put(0.
Since closure_put() would now otherwise just have a release barrier, we
also need a new barrier when the ref hits 0 -
smp_acquire__after_ctrl_dep().
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
---
include/linux/closure.h | 2 --
lib/closure.c | 6 ++++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/closure.h b/include/linux/closure.h
index 722a586bb224..bdab17050bc8 100644
--- a/include/linux/closure.h
+++ b/include/linux/closure.h
@@ -233,8 +233,6 @@ static inline void set_closure_fn(struct closure *cl, closure_fn *fn,
closure_set_ip(cl);
cl->fn = fn;
cl->wq = wq;
- /* between atomic_dec() in closure_put() */
- smp_mb__before_atomic();
}
static inline void closure_queue(struct closure *cl)
diff --git a/lib/closure.c b/lib/closure.c
index 0855e698ced1..501dfa277b59 100644
--- a/lib/closure.c
+++ b/lib/closure.c
@@ -21,6 +21,8 @@ static inline void closure_put_after_sub(struct closure *cl, int flags)
BUG_ON(!r && (flags & ~CLOSURE_DESTRUCTOR));
if (!r) {
+ smp_acquire__after_ctrl_dep();
+
if (cl->fn && !(flags & CLOSURE_DESTRUCTOR)) {
atomic_set(&cl->remaining,
CLOSURE_REMAINING_INITIALIZER);
@@ -43,7 +45,7 @@ static inline void closure_put_after_sub(struct closure *cl, int flags)
/* For clearing flags with the same atomic op as a put */
void closure_sub(struct closure *cl, int v)
{
- closure_put_after_sub(cl, atomic_sub_return(v, &cl->remaining));
+ closure_put_after_sub(cl, atomic_sub_return_release(v, &cl->remaining));
}
EXPORT_SYMBOL(closure_sub);
@@ -52,7 +54,7 @@ EXPORT_SYMBOL(closure_sub);
*/
void closure_put(struct closure *cl)
{
- closure_put_after_sub(cl, atomic_dec_return(&cl->remaining));
+ closure_put_after_sub(cl, atomic_dec_return_release(&cl->remaining));
}
EXPORT_SYMBOL(closure_put);
--
2.42.0
next prev parent reply other threads:[~2023-10-31 16:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-31 16:24 [PATCH 0/2] Two small closures patches Kent Overstreet
2023-10-31 16:24 ` Kent Overstreet [this message]
2023-10-31 16:24 ` [PATCH 2/2] closures: Fix race in closure_sync() Kent Overstreet
2023-11-18 16:43 ` [PATCH 0/2] Two small closures patches Coly Li
2023-11-18 17:20 ` Coly Li
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=20231031162454.3761482-2-kent.overstreet@linux.dev \
--to=kent.overstreet@linux.dev \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-bcachefs@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.