From: Steven Rostedt <rostedt@goodmis.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: John Stultz <jstultz@google.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Christian Loehle <christian.loehle@arm.com>,
Qais Yousef <qyousef@google.com>,
LKML <linux-kernel@vger.kernel.org>,
Hongyan Xia <hongyan.xia2@arm.com>,
Ingo Molnar <mingo@kernel.org>, Wei Wang <wvw@google.com>,
Patrick Bellasi <patrick.bellasi@arm.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>
Subject: Re: Uclamp races due to non-atomic static_branch_likely updates
Date: Wed, 21 Oct 2026 09:21:36 -0400 [thread overview]
Message-ID: <20261021092136.249e2d19@gandalf.local.home> (raw)
In-Reply-To: <20261021113806.GE2823843@noisy.programming.kicks-ass.net>
On Wed, 21 Oct 2026 13:38:06 +0200
Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, Oct 20, 2026 at 03:29:33PM -0400, Steven Rostedt wrote:
> > On Tue, 20 Oct 2026 11:53:47 -0700
> > John Stultz <jstultz@google.com> wrote:
> >
> > > Maybe should the jump_label_update() logic be using something like
> > > stop_machine? Or should there still be a conditional on key->enabled
> > > in the unlikely case to make the behavior consistent? Or is there just
> > > something about the uclamp usage that is off?
> >
> > There's never been any guarantee that all call sites would update
> > atomically. The first user of jump labels was tracepoints and I really do
> > not want stop machine involved with them.
> >
> > Perhaps we could add an api like static_key_enable_atomic() and
> > static_key_disable_atomic() that would go through a stop_machine() and
> > update everything that way for those locations that need an atomic view of
> > the updated jump labels.
>
> Argh, no, we do not want people to 'accidentally' add stop_machine()
> usage, which we then have to spend tons of time on removing again.
OK, sure. I was a bit skeptical of that approach too.
>
> And yeah, its always been the case that jump_labels (and static_branch)
> updates are non-atomic. Most of them are init time, and don't care.
>
> Now, I'm sure we've ran into this particular problem before, and it
> always requires care.
>
> Also note that a simple global boolean has the exact same problem.
> Adding runtime conditionals isn't going to fix this.
Another idea for "atomic static branch" is to have two static branches at
each location. One that switches to a "check this variable and do a normal
test and branch" and "we are now in sync and can use the original static
branch".
Something like:
if (static_branch_unlikely(&foo_use_variable.key)) {
return static_key_enabled(&foo->key);
} else {
if (static_branch_unlikely(&foo->key))
return true;
else
return false;
}
And then in between updates of foo, the foo_use_variable gets set making
all the branches use the key, which will be updated "atomically" (maybe
some memory barriers needs to be added). After the updates of all the
static keys are complete, the foo_use_variable gets unset.
The non-atomic portion of "foo_use_variable" is OK because the foo->key
will match whatever the static_branch version it has.
The end result avoids the test and branch but will have two nop/jmp pairs.
-- Steve
next prev parent reply other threads:[~2026-10-21 13:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 18:53 John Stultz
2026-10-20 19:29 ` Steven Rostedt
2026-10-21 11:38 ` Peter Zijlstra
2026-10-21 13:20 ` Qais Yousef
2026-10-21 13:29 ` Peter Zijlstra
2026-10-21 14:02 ` Qais Yousef
2026-10-21 13:21 ` Steven Rostedt [this message]
2026-10-21 13:34 ` Peter Zijlstra
2026-10-21 13:59 ` Steven Rostedt
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=20261021092136.249e2d19@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=christian.loehle@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=hongyan.xia2@arm.com \
--cc=jstultz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=patrick.bellasi@arm.com \
--cc=peterz@infradead.org \
--cc=qyousef@google.com \
--cc=vincent.guittot@linaro.org \
--cc=wvw@google.com \
/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
all inboxes | Powered by JetHome®