Removing __get_user / __put_user for good

Removing __get_user / __put_user for good

[Linus Torvalds]

Bah. I made this branch of mine public because I wanted Michael
Tsirkin to check the vhost part.

But honestly, the i915 side and the coco/SEV patches are the much more
interesting ones.

So this brings in some new victims^Hpeople for that git branch to comment on.

It's all in

  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
uaccess-cleanup

I haven't dared actually boot it yet.

                    Linus

On Mon, 19 Oct 2026 at 20:51, Linus Torvalds
<torvalds@linuxfoundation.org> wrote:
>
> I have a whole branch that removes __get_user() and __put_user() entirely.
>
> Somebody should check that I did it right. But I didn't want to do the
> pagefault_disable() around the vringh_notify() part, so it's not quite
> the same as yours.
>
> Let me just push it out. I was going to let it simmer, but your email
> made me go "I should just let more people look at it".
>
> Mind taking a look at the 'uaccess-cleanups' branch?
>
> It builds for me. That's all the testing it has gotten so far. Blush.
>
>                    Linus

Re: Removing __get_user / __put_user for good

[Jani Nikula]

On Mon, 19 Oct 2026, Linus Torvalds <torvalds@linuxfoundation.org> wrote:
> Bah. I made this branch of mine public because I wanted Michael
> Tsirkin to check the vhost part.
>
> But honestly, the i915 side and the coco/SEV patches are the much more
> interesting ones.
>
> So this brings in some new victims^Hpeople for that git branch to comment on.
>
> It's all in
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> uaccess-cleanup
>
> I haven't dared actually boot it yet.

I rebased it on top of our development branch and sent it to i915
CI. Let's see if it blows up. ;)


BR,
Jani.


-- 
Jani Nikula, Intel

Re: Removing __get_user / __put_user for good

[Michael S. Tsirkin]

On Mon, Oct 19, 2026 at 09:25:02PM -1000, Linus Torvalds wrote:
> Bah. I made this branch of mine public because I wanted Michael
> Tsirkin to check the vhost part.
> 
> But honestly, the i915 side and the coco/SEV patches are the much more
> interesting ones.
> 
> So this brings in some new victims^Hpeople for that git branch to comment on.
> 
> It's all in
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> uaccess-cleanup
> 
> I haven't dared actually boot it yet.
> 
>                     Linus

vpda seems to survive light testing in a VM for me.

Tested-by: Michael S. Tsirkin <mst@redhat.com>


It's still buggy if there is a swapout right before
the access, just like it was previously, but hey.
One splat less. An improvement.

You might want:

Fixes: 42823a871fd4 ("vringh: support VA with iotlb")

with that, vdpa/vhost bits:

Acked-by: Michael S. Tsirkin <mst@redhat.com>



> On Mon, 19 Oct 2026 at 20:51, Linus Torvalds
> <torvalds@linuxfoundation.org> wrote:
> >
> > I have a whole branch that removes __get_user() and __put_user() entirely.
> >
> > Somebody should check that I did it right. But I didn't want to do the
> > pagefault_disable() around the vringh_notify() part, so it's not quite
> > the same as yours.
> >
> > Let me just push it out. I was going to let it simmer, but your email
> > made me go "I should just let more people look at it".
> >
> > Mind taking a look at the 'uaccess-cleanups' branch?
> >
> > It builds for me. That's all the testing it has gotten so far. Blush.
> >
> >                    Linus

Re: Removing __get_user / __put_user for good

[Ingo Molnar]

* Linus Torvalds <torvalds@linuxfoundation.org> wrote:

> Bah. I made this branch of mine public because I wanted Michael
> Tsirkin to check the vhost part.
> 
> But honestly, the i915 side and the coco/SEV patches are the much more
> interesting ones.
> 
> So this brings in some new victims^Hpeople for that git branch to comment on.
> 
> It's all in
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> uaccess-cleanup

So it's 'uaccess-cleanups', plural, in case someone copy & pasted
this URI verbatim instead of using the branch name from your
earlier mail. :-)

All the x86 cleanups look good to me in principle, and a quick
test-build & boot shows no problems (both on 64-bit and 32-bit),
but regular testing doesn't fully excercise the exception paths
of these changes, so YMMV.

( BTW., there's a new dependency introduced by this series,
  if an architecture gets rid of __get_user(), then it must
  define arch_get_kernel_nofault(), otherwise it will gain
  new uses of __get_user()/__put_user() via the generic implementations
  of __get_kernel_nofault() and __put_kernel_nofault(). No big deal
  I suppose. )

Thanks,

	Ingo

Re: Removing __get_user / __put_user for good

[Linus Torvalds]

On Tue, 20 Oct 2026 at 03:19, Ingo Molnar <mingo@kernel.org> wrote:
>
> ( BTW., there's a new dependency introduced by this series,
>   if an architecture gets rid of __get_user(), then it must
>   define arch_get_kernel_nofault(), otherwise it will gain
>   new uses of __get_user()/__put_user() via the generic implementations
>   of __get_kernel_nofault() and __put_kernel_nofault(). No big deal
>   I suppose. )

Yeah. It didn't actually look too bad to just remove __get_user and
__put_user in general, but I ran out of motivation.

On arm64, it's a non-issue: __get/put_user is the same thing as
get/put_user, and they both do the full checks.

And the bulk of the remaining cases were on architectures that I
didn't feel were a big issue: alpha/mips/sparc.

I *think* they are all trivial - the bulk of them are just the
historical signal stack stuff and should be a direct conversion to
unsafe_get/put_user() wrapped with scoped_user_read/write_access().

So I think 90% of the remaining noise is truly trivial - not like some
of the cases that actually had *semantic* reasons to use
__get/put_user (often very _bad_ semantic reasons, but still).

Not a huge deal, I might get around to it while waiting for test
builds. Or I might not.

                 Linus

Re: Removing __get_user / __put_user for good

[Linus Torvalds]

On Tue, 20 Oct 2026 at 08:14, Linus Torvalds
<torvalds@linuxfoundation.org> wrote:
>
> On Tue, 20 Oct 2026 at 03:19, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > ( BTW., there's a new dependency introduced by this series,
> >   if an architecture gets rid of __get_user(), then it must
> >   define arch_get_kernel_nofault(), otherwise it will gain
> >   new uses of __get_user()/__put_user() via the generic implementations
> >   of __get_kernel_nofault() and __put_kernel_nofault(). No big deal
> >   I suppose. )
>
> Yeah. It didn't actually look too bad to just remove __get_user and
> __put_user in general, but I ran out of motivation.

Bah. I'm using claude as a fancy coccinelle script, and ended up doing
the ObviouslyCorrect(tm) safe cases.

And it all really does look obviously correct, but ...

Anyway, the branch has been partially rebased to add the acked-by from
Michael, and now has a number of those "obvious" patches for alpha,
hexagon, 32-bit arm and powerpc.

I think I have - once again - run out of motivation to go further.
There are still various __get_user and __put_user calls around, but
they are starting to get rare, and I've run out of cases that look
obvious.

For example, I looked at the sparc32 signal cases, and decided
somebody else needs to do that part. It just looks too messy, and I
can't find it in myself to care. Same goes for m68k, loongarch, parisc
and mips. I just ran out of steam.

But I think this *did* get rid of the bulk of the noise elsewhere, so
now it's hopefully a case of "a motivated architecture maintainer has
a few cases to look at".

                 Linus

Re: Removing __get_user / __put_user for good

[Linus Torvalds]

On Tue, 20 Oct 2026 at 11:10, Linus Torvalds
<torvalds@linuxfoundation.org> wrote:
>
> And it all really does look obviously correct, but ...

I think I'm just gping to merge this. I don't love all the changes,
but I love __get_user and __put_user less.

And the one change that makes me worry most is the i915 one, and I
have at least minimally tested that one by virtue of now actually
running the code in question on my laptop that does indeed have i915
integrated graphics.

It does change semantics, but it does so in a situation where I really
do think that the old code was actively buggy and would have triggered
a lockdep splat if it hit that situation.

The i915 code also was actively wrong in its comments about this all,
with some of it going back to some stone age code with
'verify_area(VERIFY_WRITE)' that used to actually trigger page faults
on i386 in order to do early COW.

We haven't done that since the 2.5.x days, and even then we only ever
did it on 32-bit kernels and only if CONFIG_X86_WP_WORKS_OK wasn't
enabled.

Put another way: I'm not claiming my patches are perfect, but I think
they are an improvement, and I'd rather merge this early and find any
issues than keep known-broken code around.

And yes, I might have missed some situation where __get/put_user() was
used for some reason I overlooked.

The reasons I at least thought about:

 - the legacy case of "one single access_ok and multiple __get_users
is faster" case

   This is not faster any more, and hasn't been for years and years.
But the cases I thought might care about performance - or the cases
that were trivial to convert - got converted with
"scoped_user_read/write_begin() {}" and unsafe_get/put_user() calls,
so now they *really* are faster.

 - The vhost use-case that wants to use get_user() in atomic context,
but used __get_user() in order to avoid a warning

   The warning was *correct*, and using __get_user() was a bug waiting
to happen, because some atomic situations aren't visible at runtime.
The fix is to actually use pagefault_disable/enable() and get_user()
to make this all explicit, avoid the warning, and avoid the issue that
some atomic sections aren't even visible in the preempt count.

 - The "either kernel or user pointer" situation. That was the x86
coco/SEV case, and the alpha "is_prefetch" cases.

 - A couple of "kernel pointer only" cases that should just use
"get_kernel_nofault()", but the code pre-dates that helper existing.

but it is possible that there is some case I didn't catch. Still, this
"remove __get/put_user" is way over-due and now that I finally got it
done, I don't want to leave it hanging.

                   Linus

Re: Removing __get_user / __put_user for good

[Borislav Petkov]

On Tue, Oct 20, 2026 at 03:38:02PM -1000, Linus Torvalds wrote:
>  - The "either kernel or user pointer" situation. That was the x86
> coco/SEV case, and the alpha "is_prefetch" cases.

My SEV-SNP guest boots with it and we'll run more extensive tests soon to make
sure nothing falls out.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: Removing __get_user / __put_user for good

[Linus Torvalds]

On Tue, 20 Oct 2026 at 16:54, Borislav Petkov <bp@alien8.de> wrote:
>
> My SEV-SNP guest boots with it and we'll run more extensive tests soon to make
> sure nothing falls out.

I don't know that code at all, but from my reading it will only
trigger in fairly unusual cases ("rep movs/ins/outs" that need
emulation).

But the replacement code *should* do what __get_user/__put_user did
before, just with a local helper, so unlike the i915 case it shouldn't
actually change any semantics.

Famous last words... It's the largest of the patches (well, I'm
ignoring the ones that just do multiple accesses to the same signal
frame - they may be more lines, but it's just the same thing repeated
over and over again).

             Linus

Re: Removing __get_user / __put_user for good

[Ingo Molnar]

* Linus Torvalds <torvalds@linuxfoundation.org> wrote:

> On Tue, 20 Oct 2026 at 11:10, Linus Torvalds
> <torvalds@linuxfoundation.org> wrote:
> >
> > And it all really does look obviously correct, but ...
> 
> I think I'm just gping to merge this. I don't love all the changes,
> but I love __get_user and __put_user less.

Good riddance in any case, and for the x86 bits:

	Acked-by: Ingo Molnar <mingo@kernel.org>

Thanks,

	Ingo

Re: Removing __get_user / __put_user for good

[Rodrigo Vivi]

On Tue, Oct 20, 2026 at 12:33:58PM +0300, Jani Nikula wrote:
> On Mon, 19 Oct 2026, Linus Torvalds <torvalds@linuxfoundation.org> wrote:
> > Bah. I made this branch of mine public because I wanted Michael
> > Tsirkin to check the vhost part.
> >
> > But honestly, the i915 side and the coco/SEV patches are the much more
> > interesting ones.
> >
> > So this brings in some new victims^Hpeople for that git branch to comment on.
> >
> > It's all in
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > uaccess-cleanup
> >
> > I haven't dared actually boot it yet.
> 
> I rebased it on top of our development branch and sent it to i915
> CI. Let's see if it blows up. ;)

The new commit 'drm/i915/gem: Don't fault on presumed_offset write-back' [1]

reverts commit '97a37c919f62 ("drm/i915/gem: Ignore readonly failures when
updating relocs")'

And this blows up exec_reloc concurrent tests that uses
mprotect(reloc, sz, PROT_READ); [2]

I'm not sure if this is a real use case though...

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Andi Shyti <andi.shyti@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Folks, can you please help here?

[1] - https://github.com/torvalds/linux/commit/03c19e449ac6e12a88ea4866331f2404668e22cc
[2] - https://patchwork.freedesktop.org/series/176471/

> 
> 
> BR,
> Jani.
> 
> 
> -- 
> Jani Nikula, Intel

Re: Removing __get_user / __put_user for good

[Linus Torvalds]

On Wed, 21 Oct 2026 at 06:36, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
>
> The new commit 'drm/i915/gem: Don't fault on presumed_offset write-back' [1]
>
> reverts commit '97a37c919f62 ("drm/i915/gem: Ignore readonly failures when
> updating relocs")'
>
> And this blows up exec_reloc concurrent tests that uses
> mprotect(reloc, sz, PROT_READ); [2]

The old code had two separate bugs:

 - it used __put_user() while holding locks that could deadlock with
fault handling

   Fixed with the pagefault_disable() around the put_user()

 - it didn't actually check failures, so a read-only area silently
just dropped the write

   Fixed with that "if (unlikely(err))" addition

But yes, I didn't see that the error handling had been removed - the
removal didn't show up in the code

So I'll remove the error handling from me branch before merging.

But that code absolutely smells, though. It makes no sense to silently
drop the relocations and just go on - and continue in that loop that
will then drop the next one. And the one after.. You're just wasting
CPU time and doing nothing useful.

So I will merge it with that error handling removed, but I suspect
that test is bogus garbage, and was testing for a bug, not testing for
actual behavior. But I may be wrong.

But the __put_user() and the pagefault_disable() around it stays.  The
old code was very very buggy - and not in a "waste CPU time" way, but
in a "you could cause deadlocks and lockdep issues" kind of way.

                  Linus

Re: Removing __get_user / __put_user for good

[Borislav Petkov]

On Tue, Oct 20, 2026 at 05:00:46PM -1000, Linus Torvalds wrote:
> I don't know that code at all, but from my reading it will only
> trigger in fairly unusual cases ("rep movs/ins/outs" that need
> emulation).

Right, and when the src/dst are MMIO, see 

        case INSN_MMIO_MOVS:
                ret = vc_handle_mmio_movs(ctxt, bytes);

which calls that vc_*_mem() gunk.

I presume you've also found:

  4954f5b8ef0b ("x86/sev-es: Use __put_user()/__get_user() for data accesses")

which explains why we use those.

> But the replacement code *should* do what __get_user/__put_user did
> before, just with a local helper, so unlike the i915 case it shouldn't
> actually change any semantics.

Yeah, I wanted to take a detailed look on a fresh head but you pulled it
again. :-P

I'll have a look when it shows up again.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: Removing __get_user / __put_user for good

[Linus Torvalds]

On Wed, 21 Oct 2026 at 08:43, Borislav Petkov <bp@alien8.de> wrote:
>
> Yeah, I wanted to take a detailed look on a fresh head but you pulled it
> again. :-P

Ahh, I removed it because I merged it locally, but then I decided I
should do a full build before I push it all out because I had missed a
merge error yesterday due to not doing a proper full build on my poor
little laptop.

So yeah, it's gone, but it will show up in master shortly.

And by "shortly" I mean "not as shortly as it would have happened on
my home machine".

I think I need to upgrade my laptop eventually. It's a perfectly fine
laptop, but it's from 2019. I'm sure there are more powerful ones out
there that are still lightweight.

        Linus

Re: Removing __get_user / __put_user for good

[Borislav Petkov]

On Wed, Oct 21, 2026 at 08:55:39AM -1000, Linus Torvalds wrote:
> I think I need to upgrade my laptop eventually. It's a perfectly fine
> laptop, but it's from 2019. I'm sure there are more powerful ones out
> there that are still lightweight.

Yeah, I love a laptop because it is nice and silent but no matter how big it
is, allmodconfig is still faaat and takes foreva. So I've scripted all my
builds to go to test machines and the laptop is simply collecting results or
booting those kernel binaries in VMs and so on.

That's how I follow the merge order of when we send you tip branches and I go
and merge and build each one to check for build errors one last time and see
what merge conflicts will appear.

And I can't do that on a laptop. It just takes too long.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette