From: David Laight <david.laight.linux@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>,
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>,
Darren Hart <dvhart@infradead.org>,
Davidlohr Bueso <dave@stgolabs.net>,
Andre Almeida <andrealmeid@igalia.com>,
Andrew Morton <akpm@linux-foundation.org>,
Eric Dumazet <edumazet@google.com>,
Kuniyuki Iwashima <kuniyu@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Willem de Bruijn <willemb@google.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Simon Horman <horms@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Dave Hansen <dave.hansen@linux.intel.com>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v4 10/10] powerpc/uaccess: Implement masked user access
Date: Thu, 6 Nov 2025 13:42:55 +0000 [thread overview]
Message-ID: <20251106134255.2412971a@pumpkin> (raw)
In-Reply-To: <20251106123550.GX4067720@noisy.programming.kicks-ass.net>
On Thu, 6 Nov 2025 13:35:50 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, Nov 06, 2025 at 12:31:28PM +0100, Christophe Leroy wrote:
>
> > On 32 bits it is more tricky. In theory user space can go up to
> > 0xbfffffff while kernel will usually start at 0xc0000000. So a gap
> > needs to be added in-between. Allthough in theory a single 4k page
Although
> > would suffice, it is easier and more efficient to enforce a 128k gap
> > below kernel, as it simplifies the masking.
>
> Do we have the requirement that the first access of a masked pointer is
> within 4k of the initial address?
>
> Suppose the pointer is to an 16k array, and the memcpy happens to like
> going backwards. Then a 4k hole just won't do.
I think that requiring the accesses be within 4k of the base (or previous
access) is a reasonable restriction.
It is something that needs verifying before code is changed to use
these accessors.
Documenting a big gap is almost more likely to lead to errors!
If 128k is ok, no one is really going to notice code that might
offset by 130k.
OTOH if the (documented) limit is 256 bytes then you don't have to be
careful about accessing structures sequentially, and can safely realign
pointers.
I suspect the mk-1 brain treats 4k and 256 as muchthe same value.
Requiring fully sequential accesses (which the original x86-64 required
because it converted kernel addresses to ~0) would require policing by
the compiler - I tried it once, it horrid.
David
next prev parent reply other threads:[~2025-11-06 13:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-06 11:31 [PATCH v4 00/10] powerpc: Implement masked user access Christophe Leroy
2025-11-06 11:31 ` [PATCH v4 01/10] iter: Avoid barrier_nospec() in copy_from_user_iter() Christophe Leroy
2025-11-06 11:31 ` [PATCH v4 02/10] uaccess: Add speculation barrier to copy_from_user_iter() Christophe Leroy
2025-11-06 11:31 ` [PATCH v4 03/10] uaccess: Use masked_user_{read/write}_access_begin when required Christophe Leroy
2025-11-06 11:31 ` [PATCH v4 04/10] powerpc/uaccess: Move barrier_nospec() out of allow_read_{from/write}_user() Christophe Leroy
2025-11-06 11:31 ` [PATCH v4 05/10] powerpc/uaccess: Remove unused size and from parameters from allow_access_user() Christophe Leroy
2025-11-06 11:31 ` [PATCH v4 06/10] powerpc/uaccess: Remove {allow/prevent}_{read/write/read_write}_{from/to/}_user() Christophe Leroy
2025-11-06 11:31 ` [PATCH v4 07/10] powerpc/uaccess: Refactor user_{read/write/}_access_begin() Christophe Leroy
2025-11-06 11:31 ` [PATCH v4 08/10] powerpc/32s: Fix segments setup when TASK_SIZE is not a multiple of 256M Christophe Leroy
2025-11-06 11:31 ` [PATCH v4 09/10] powerpc/32: Automatically adapt TASK_SIZE based on constraints Christophe Leroy
2025-11-06 11:31 ` [PATCH v4 10/10] powerpc/uaccess: Implement masked user access Christophe Leroy
2025-11-06 12:35 ` Peter Zijlstra
2025-11-06 13:42 ` David Laight [this message]
2025-11-13 6:10 ` [PATCH v4 00/10] powerpc: " Madhavan Srinivasan
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=20251106134255.2412971a@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andrealmeid@igalia.com \
--cc=brauner@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=daniel@iogearbox.net \
--cc=dave.hansen@linux.intel.com \
--cc=dave@stgolabs.net \
--cc=davem@davemloft.net \
--cc=dvhart@infradead.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jack@suse.cz \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=netdev@vger.kernel.org \
--cc=npiggin@gmail.com \
--cc=pabeni@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
--cc=willemb@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;
as well as URLs for NNTP newsgroup(s).