[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251114190856.7e438d9d@pumpkin>
Date: Fri, 14 Nov 2025 19:08:56 +0000
From: David Laight <david.laight.linux@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Jon Kohler <jon@...anix.com>, Jason Wang <jasowang@...hat.com>, "Michael
S. Tsirkin" <mst@...hat.com>, Eugenio Pérez
<eperezma@...hat.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"virtualization@...ts.linux.dev" <virtualization@...ts.linux.dev>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Borislav
Petkov <bp@...en8.de>, Sean Christopherson <seanjc@...gle.com>
Subject: Re: [PATCH net-next] vhost: use "checked" versions of get_user()
and put_user()
On Fri, 14 Nov 2025 09:48:02 -0800
Linus Torvalds <torvalds@...ux-foundation.org> wrote:
...
> But then get_user() gets optimized to do the address space check using
> a data dependency instead of the "access_ok()" control dependency, and
> so get_user() doesn't need LFENCE at all, and now get_user() is
> *faster* than __get_user().
I think that is currently only x86-64?
There are patches in the pipeline for ppc.
I don't think I've seen anything for arm32 or arm64.
arm64 has the issue that the hardware looks at the wrong address bit,
so might need an explicit guard page at the end of user addresses.
Changing x86-32 to have a guard page ought to be straightforward.
But I think the user stack ends right at 0xc000000 (with argv[] and env[])
so it might be safer to also reduce the stack size by 4k (pretending
env[] is larger) to avoid problems with code that is trying to map
things at fixed addresses just below the stack (or do we care about that?).
I'm sure I should be able to build and test the x86-32 code.
I guess there are instruction for doing that under qemu somewhere?
Might be time to drop support for cpu that don't support cmov?
David
Powered by blists - more mailing lists