From: Thomas Gleixner <tglx@linutronix.de>
To: Peter Zijlstra <peterz@infradead.org>,
"Darrick J. Wong" <djwong@kernel.org>
Cc: Chandan Babu R <chandanbabu@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
xfs <linux-xfs@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
x86@kernel.org
Subject: Re: Are jump labels broken on 6.11-rc1?
Date: Wed, 07 Aug 2024 16:03:12 +0200 [thread overview]
Message-ID: <875xsc4ehr.ffs@tglx> (raw)
In-Reply-To: <20240806103808.GT37996@noisy.programming.kicks-ass.net>
On Tue, Aug 06 2024 at 12:38, Peter Zijlstra wrote:
> On Tue, Aug 06, 2024 at 11:44:13AM +0200, Peter Zijlstra wrote:
> I've ended up with this, not exactly pretty :/
>
> -static bool static_key_slow_try_dec(struct static_key *key)
> +static bool static_key_dec(struct static_key *key, bool fast)
> {
> int v;
>
> @@ -268,31 +268,45 @@ static bool static_key_slow_try_dec(struct static_key *key)
> v = atomic_read(&key->enabled);
> do {
> /*
> - * Warn about the '-1' case though; since that means a
> - * decrement is concurrent with a first (0->1) increment. IOW
> - * people are trying to disable something that wasn't yet fully
> - * enabled. This suggests an ordering problem on the user side.
> + * Warn about the '-1' case; since that means a decrement is
> + * concurrent with a first (0->1) increment. IOW people are
> + * trying to disable something that wasn't yet fully enabled.
> + * This suggests an ordering problem on the user side.
> + *
> + * Warn about the '0' case; simple underflow.
> + *
> + * Neither case should succeed and change things.
Which is confusing because the fastpath will drop down into the slowpath
due to this.
> + */
> + if (WARN_ON_ONCE(v <= 0))
> + return false;
This forces the fastpath into the slowpath. I assume this on purpose to
handle the concurrent 'first enable (enabled == -1)'. But hell this is
not comprehensible without a comment.
> static void __static_key_slow_dec_cpuslocked(struct static_key *key)
> {
> lockdep_assert_cpus_held();
>
> - if (static_key_slow_try_dec(key))
> + if (static_key_dec(key, true)) // dec-not-one
Eeew.
Something like the below?
Thanks,
tglx
---
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -168,8 +168,8 @@ bool static_key_slow_inc_cpuslocked(stru
jump_label_update(key);
/*
* Ensure that when static_key_fast_inc_not_disabled() or
- * static_key_slow_try_dec() observe the positive value,
- * they must also observe all the text changes.
+ * static_key_dec() observe the positive value, they must also
+ * observe all the text changes.
*/
atomic_set_release(&key->enabled, 1);
} else {
@@ -250,49 +250,71 @@ void static_key_disable(struct static_ke
}
EXPORT_SYMBOL_GPL(static_key_disable);
-static bool static_key_slow_try_dec(struct static_key *key)
+static bool static_key_dec(struct static_key *key, bool dec_not_one)
{
- int v;
+ int v = atomic_read(&key->enabled);
- /*
- * Go into the slow path if key::enabled is less than or equal than
- * one. One is valid to shut down the key, anything less than one
- * is an imbalance, which is handled at the call site.
- *
- * That includes the special case of '-1' which is set in
- * static_key_slow_inc_cpuslocked(), but that's harmless as it is
- * fully serialized in the slow path below. By the time this task
- * acquires the jump label lock the value is back to one and the
- * retry under the lock must succeed.
- */
- v = atomic_read(&key->enabled);
do {
/*
- * Warn about the '-1' case though; since that means a
- * decrement is concurrent with a first (0->1) increment. IOW
- * people are trying to disable something that wasn't yet fully
- * enabled. This suggests an ordering problem on the user side.
+ * Warn about the '-1' case; since that means a decrement is
+ * concurrent with a first (0->1) increment. IOW people are
+ * trying to disable something that wasn't yet fully enabled.
+ * This suggests an ordering problem on the user side.
+ *
+ * Warn about the '0' case; simple underflow.
*/
- WARN_ON_ONCE(v < 0);
- if (v <= 1)
- return false;
+ if (WARN_ON_ONCE(v <= 0))
+ return v;
+
+ if (dec_not_one && v == 1)
+ return v;
+
} while (!likely(atomic_try_cmpxchg(&key->enabled, &v, v - 1)));
- return true;
+ return v;
+}
+
+/*
+ * Fastpath: Decrement if the reference count is greater than one
+ *
+ * Returns false, if the reference count is 1 or -1 to force the caller
+ * into the slowpath.
+ *
+ * The -1 case is to handle a decrement during a concurrent first enable,
+ * which sets the count to -1 in static_key_slow_inc_cpuslocked(). As the
+ * slow path is serialized the caller will observe 1 once it acquired the
+ * jump_label_mutex, so the slow path can succeed.
+ */
+static bool static_key_dec_not_one(struct static_key *key)
+{
+ int v = static_key_dec(key, true);
+
+ return v != 1 && v != -1;
+}
+
+/*
+ * Slowpath: Decrement and test whether the refcount hit 0.
+ *
+ * Returns true if the refcount hit zero, i.e. the previous value was one.
+ */
+static bool static_key_dec_and_test(struct static_key *key)
+{
+ int v = static_key_dec(key, false);
+
+ lockdep_assert_held(&jump_label_mutex);
+ return v == 1;
}
static void __static_key_slow_dec_cpuslocked(struct static_key *key)
{
lockdep_assert_cpus_held();
- if (static_key_slow_try_dec(key))
+ if (static_key_dec_not_one(key))
return;
guard(mutex)(&jump_label_mutex);
- if (atomic_cmpxchg(&key->enabled, 1, 0) == 1)
+ if (static_key_dec_and_test(key))
jump_label_update(key);
- else
- WARN_ON_ONCE(!static_key_slow_try_dec(key));
}
static void __static_key_slow_dec(struct static_key *key)
@@ -329,7 +351,7 @@ void __static_key_slow_dec_deferred(stru
{
STATIC_KEY_CHECK_USE(key);
- if (static_key_slow_try_dec(key))
+ if (static_key_dec_not_one(key))
return;
schedule_delayed_work(work, timeout);
next prev parent reply other threads:[~2024-08-07 14:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-30 3:38 Are jump labels broken on 6.11-rc1? Darrick J. Wong
2024-07-30 7:30 ` Chandan Babu R
2024-07-30 13:26 ` Peter Zijlstra
2024-07-30 13:59 ` Darrick J. Wong
2024-07-31 0:19 ` Darrick J. Wong
2024-07-31 3:10 ` Darrick J. Wong
2024-07-31 5:33 ` Darrick J. Wong
2024-07-31 10:55 ` Peter Zijlstra
2024-08-05 14:35 ` Darrick J. Wong
2024-08-06 9:44 ` Peter Zijlstra
2024-08-06 10:38 ` Peter Zijlstra
2024-08-06 22:01 ` Darrick J. Wong
2024-08-07 14:03 ` Thomas Gleixner [this message]
2024-08-07 14:34 ` Peter Zijlstra
2024-08-07 14:55 ` Thomas Gleixner
2024-08-07 15:05 ` Darrick J. Wong
2024-08-07 22:51 ` Darrick J. Wong
2024-08-27 3:35 ` Darrick J. Wong
2024-09-05 8:12 ` Peter Zijlstra
2024-09-05 9:16 ` Peter Zijlstra
2024-09-16 16:08 ` Darrick J. Wong
2024-09-19 23:41 ` Darrick J. Wong
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=875xsc4ehr.ffs@tglx \
--to=tglx@linutronix.de \
--cc=chandanbabu@kernel.org \
--cc=djwong@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=willy@infradead.org \
--cc=x86@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