From: David Laight <david.laight.linux@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Uros Bizjak <ubizjak@gmail.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@kernel.org>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH -tip 1/3] x86/fsgsbase: Remove unnecessary "memory" clobbers from FS/GS base accessors
Date: Tue, 10 Mar 2026 14:11:04 +0000 [thread overview]
Message-ID: <20260310141104.4c57ea79@pumpkin> (raw)
In-Reply-To: <20260310102742.GU1282955@noisy.programming.kicks-ass.net>
On Tue, 10 Mar 2026 11:27:42 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, Mar 10, 2026 at 09:21:22AM +0100, Uros Bizjak wrote:
> > The rdfsbase() and rdgsbase() helpers currently include a "memory" clobber
> > in their inline assembly definitions. However, the RDFSBASE and RDGSBASE
> > instructions only read the FS/GS base MSRs into a general-purpose register
> > and do not access memory. As such, the "memory" clobber is unnecessary.
>
> The point isn't that this accesses memory, but that prior or later
> accesses would end up at different memory locations (as would happen
> when setting the per-cpu segment.
Don't they need a "memory" clobber to stop them being moved the other
side of a request to set the relevant register?
In effect the [fg]sbase register has to be treated like a memory location.
Given that a memory clobber often makes little (or no) difference to
the generated code it is probably better to be safe and leave the clobber
in place.
If the memory clobber does make a significant difference (unlikely here)
it can often be mitigated by changing the source code to not rely on CSE.
David
>
> Anyway, aside from that nit, yes these 3 patches look good to me.
>
> >
> > No functional change intended.
> >
> > Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> > Cc: Thomas Gleixner <tglx@kernel.org>
> > Cc: Ingo Molnar <mingo@kernel.org>
> > Cc: Borislav Petkov <bp@alien8.de>
> > Cc: Dave Hansen <dave.hansen@linux.intel.com>
> > Cc: "H. Peter Anvin" <hpa@zytor.com>
> > Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
> > ---
> > arch/x86/include/asm/fsgsbase.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/fsgsbase.h b/arch/x86/include/asm/fsgsbase.h
> > index ab2547f97c2c..70ff4ef457b1 100644
> > --- a/arch/x86/include/asm/fsgsbase.h
> > +++ b/arch/x86/include/asm/fsgsbase.h
> > @@ -25,7 +25,7 @@ static __always_inline unsigned long rdfsbase(void)
> > {
> > unsigned long fsbase;
> >
> > - asm volatile("rdfsbase %0" : "=r" (fsbase) :: "memory");
> > + asm volatile("rdfsbase %0" : "=r" (fsbase));
> >
> > return fsbase;
> > }
> > @@ -34,7 +34,7 @@ static __always_inline unsigned long rdgsbase(void)
> > {
> > unsigned long gsbase;
> >
> > - asm volatile("rdgsbase %0" : "=r" (gsbase) :: "memory");
> > + asm volatile("rdgsbase %0" : "=r" (gsbase));
> >
> > return gsbase;
> > }
> > --
> > 2.53.0
> >
>
next prev parent reply other threads:[~2026-03-10 14:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 8:21 [PATCH -tip 1/3] x86/fsgsbase: Remove unnecessary "memory" clobbers from FS/GS base accessors Uros Bizjak
2026-03-10 8:21 ` [PATCH -tip 2/3] x86/segment: Remove unnecessary memory clobber from savesegment() Uros Bizjak
2026-03-10 8:21 ` [PATCH -tip 3/3] x86/segment: Use ASM_INPUT_RM in __loadsegment_fs() Uros Bizjak
2026-03-10 10:27 ` [PATCH -tip 1/3] x86/fsgsbase: Remove unnecessary "memory" clobbers from FS/GS base accessors Peter Zijlstra
2026-03-10 14:11 ` David Laight [this message]
2026-03-10 14:12 ` Peter Zijlstra
2026-03-10 15:48 ` Uros Bizjak
2026-03-10 18:11 ` Peter Zijlstra
2026-03-10 18:27 ` Uros Bizjak
2026-03-10 14:59 ` Uros Bizjak
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=20260310141104.4c57ea79@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@kernel.org \
--cc=ubizjak@gmail.com \
--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 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.