From: Segher Boessenkool <segher@kernel.crashing.org>
To: David Laight <david.laight.linux@gmail.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Naveen N Rao <naveen@kernel.org>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Darren Hart <dvhart@infradead.org>,
Davidlohr Bueso <dave@stgolabs.net>,
Andre Almeida <andrealmeid@igalia.com>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 5/5] powerpc: Implement masked user access
Date: Sun, 22 Jun 2025 13:57:06 -0500 [thread overview]
Message-ID: <20250622185706.GB17294@gate.crashing.org> (raw)
In-Reply-To: <20250622181351.08141b50@pumpkin>
Hi!
On Sun, Jun 22, 2025 at 06:13:51PM +0100, David Laight wrote:
> On Sun, 22 Jun 2025 11:52:43 +0200
> Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
> > e500 has the isel instruction which allows selecting one value or
> > the other without branch and that instruction is not speculative, so
> > use it. Allthough GCC usually generates code using that instruction,
> > it is safer to use inline assembly to be sure. The result is:
The instruction (which is a standard Power instruction since
architecture version 2.03, published in 2006) can in principle be
speculative, but there exist no Power implementations that do any data
speculation like this at all.
If you want any particular machine instructions to be generated you have
to manually write it, sure, in inline asm or preferably in actual asm.
But you can be sure that GCC will generate isel or similar (like the
v3.1 set[n]bc[r] insns, best instructions ever!), whenever appropriate,
i.e. when it is a) allowed at all, and b) advantageous.
> > 14: 3d 20 bf fe lis r9,-16386
> > 18: 7c 03 48 40 cmplw r3,r9
> > 1c: 7c 69 18 5e iselgt r3,r9,r3
> >
> > On other ones, when kernel space is over 0x80000000 and user space
> > is below, the logic in mask_user_address_simple() leads to a
> > 3 instruction sequence:
> >
> > 14: 7c 69 fe 70 srawi r9,r3,31
> > 18: 7c 63 48 78 andc r3,r3,r9
> > 1c: 51 23 00 00 rlwimi r3,r9,0,0,0
> >
> > This is the default on powerpc 8xx.
> >
> > When the limit between user space and kernel space is not 0x80000000,
> > mask_user_address_32() is used and a 6 instructions sequence is
> > generated:
> >
> > 24: 54 69 7c 7e srwi r9,r3,17
> > 28: 21 29 57 ff subfic r9,r9,22527
> > 2c: 7d 29 fe 70 srawi r9,r9,31
> > 30: 75 2a b0 00 andis. r10,r9,45056
> > 34: 7c 63 48 78 andc r3,r3,r9
> > 38: 7c 63 53 78 or r3,r3,r10
> >
> > The constraint is that TASK_SIZE be aligned to 128K in order to get
> > the most optimal number of instructions.
> >
> > When CONFIG_PPC_BARRIER_NOSPEC is not defined, fallback on the
> > test-based masking as it is quicker than the 6 instructions sequence
> > but not necessarily quicker than the 3 instructions sequences above.
>
> Doesn't that depend on whether the branch is predicted correctly?
>
> I can't read ppc asm well enough to check the above.
[ PowerPC or Power (or Power Architecture, or Power ISA) ]
> And the C is also a bit tortuous.
I can read the code ;-) All those instructions are normal simple
integer instructions. Shifts, adds, logicals.
In general, correctly predicted non-taken bvranches cost absolutely
nothing. Correctly predicted taken branches cost the same as any taken
branch, so a refetch, maybe resulting in a cycle or so of decode bubble.
And a mispredicted branch can be very expensive, say on the order of a
hundred cycles (but usually more like ten, which is still a lot of insns
worth).
So branches are great for predictable stuff, and "not so great" for
not so predictable stuff.
Segher
next prev parent reply other threads:[~2025-06-22 19:05 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-22 9:52 [PATCH 0/5] " Christophe Leroy
2025-06-22 9:52 ` [PATCH 1/5] uaccess: Add masked_user_{read/write}_access_begin Christophe Leroy
2025-06-22 16:35 ` David Laight
2025-06-24 5:34 ` Christophe Leroy
2025-06-22 9:52 ` [PATCH 2/5] uaccess: Add speculation barrier to copy_from_user_iter() Christophe Leroy
2025-06-22 16:52 ` David Laight
2025-06-22 16:57 ` Linus Torvalds
2025-06-22 20:18 ` David Laight
2025-06-24 5:49 ` Christophe Leroy
2025-06-24 8:07 ` David Laight
2025-06-24 15:15 ` Linus Torvalds
2025-06-22 9:52 ` [PATCH 3/5] powerpc: Remove unused size parametre to KUAP enabling/disabling functions Christophe Leroy
2025-06-22 9:52 ` [PATCH 4/5] powerpc: Move barrier_nospec() out of allow_read_{from/write}_user() Christophe Leroy
2025-06-22 9:52 ` [PATCH 5/5] powerpc: Implement masked user access Christophe Leroy
2025-06-22 17:13 ` David Laight
2025-06-22 17:40 ` Linus Torvalds
2025-06-22 19:51 ` David Laight
2025-06-22 18:57 ` Segher Boessenkool [this message]
2025-06-22 16:20 ` [PATCH 0/5] " David Laight
2025-06-24 5:27 ` Christophe Leroy
2025-06-24 8:32 ` David Laight
2025-06-24 21:37 ` Segher Boessenkool
2025-06-25 8:30 ` David Laight
2025-06-24 13:17 ` Segher Boessenkool
2025-06-24 16:50 ` David Laight
2025-06-24 18:25 ` Segher Boessenkool
2025-06-24 21:08 ` David Laight
2025-06-26 5:56 ` Christophe Leroy
2025-06-26 22:01 ` Segher Boessenkool
2025-07-05 10:55 ` Christophe Leroy
2025-07-05 11:42 ` Segher Boessenkool
2025-07-05 18:33 ` David Laight
2025-07-05 20:15 ` Segher Boessenkool
2025-07-05 21:05 ` David Laight
2025-07-05 21:37 ` Segher Boessenkool
2025-06-26 21:39 ` Segher Boessenkool
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=20250622185706.GB17294@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=akpm@linux-foundation.org \
--cc=andrealmeid@igalia.com \
--cc=brauner@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=dave.hansen@linux.intel.com \
--cc=dave@stgolabs.net \
--cc=david.laight.linux@gmail.com \
--cc=dvhart@infradead.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=naveen@kernel.org \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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