On Sun, 24 Nov 2024 at 08:11, David Laight wrote:
>
> Is there an 'unsafe_get_user_nofault()' that uses a trap handler
> that won't fault in a page?
Nope. I was thinking about the same thing, but we actually don't look
up the fault handler early - we only do it at failure time.
So the pagefault_
From: Linus Torvalds
> Sent: 22 November 2024 19:35
>
> On Fri, 22 Nov 2024 at 11:13, Linus Torvalds
> wrote:
> >
> > I've only compiled it so far, about to actually boot into it.
>
> Looks fine. Sent out a proper patch with commit message etc at
>
>
> https://lore.kernel.org/all/2024112219
On Fri, 22 Nov 2024 at 11:13, Linus Torvalds
wrote:
>
> I've only compiled it so far, about to actually boot into it.
Looks fine. Sent out a proper patch with commit message etc at
https://lore.kernel.org/all/20241122193305.7316-1-torva...@linux-foundation.org/
because it looks good to me.
On Thu, 21 Nov 2024 at 19:57, Linus Torvalds
wrote:
>
> Anyway, that was a long way of saying: I really think we should just
> special-case the (few) important cases that get reported. Because any
> *big* improvements will come not from just inlining.
Looking around at the futex code some more, I
On Fri, 22 Nov 2024 at 01:20, Christophe Leroy
wrote:
>
> On powerpc for this kind of stuff I have been using do { } while (0);
> with a break; in the middle, see for instance __put_user() or
> __get_user_size_allowed() in arch/powerpc/include/asm/uaccess.h
Oh, that's indeed a nicer syntax. I'll
From: Linus Torvalds
> Sent: 21 November 2024 22:16
>
> On Thu, 21 Nov 2024 at 13:40, Josh Poimboeuf wrote:
> >
> > The profile is showing futex_get_value_locked():
>
> Ahh.
>
> > That has several callers, so we can probably just use get_user() there?
>
> Yeah, that's the simplest thing. That
Le 22/11/2024 à 04:57, Linus Torvalds a écrit :
I'm not loving the "if (0)" with the labels inside of it. But it's the
only way I can see to make a statement expression like this work,
since you can't have a "return" inside of it.
On powerpc for this kind of stuff I have been using do { }
On Thu, 21 Nov 2024 at 19:11, Josh Poimboeuf wrote:
>
> On Thu, Nov 21, 2024 at 05:02:06PM -0800, Linus Torvalds wrote:
> > [ Time passes ]
> >
> > Ugh. I tried it. It looks like this:
> >
> > #define inlined_get_user(res, ptr) ({ \
> > __label__ fail2, fail1;
On Thu, Nov 21, 2024 at 05:02:06PM -0800, Linus Torvalds wrote:
> [ Time passes ]
>
> Ugh. I tried it. It looks like this:
>
> #define inlined_get_user(res, ptr) ({ \
> __label__ fail2, fail1; \
> __auto_type __up = (ptr);
On Thu, 21 Nov 2024 at 16:12, Josh Poimboeuf wrote:
>
> The asm looks good, but the C exploded a bit... why not just have an
> inline get_user()?
That was originally one of my goals for the "unsafe" ones - if done
right, they'd be the proper building blocks for a get_user(), and we'd
only really
On Thu, Nov 21, 2024 at 02:16:12PM -0800, Linus Torvalds wrote:
> mov%gs:0x0,%rax # current
> incl 0x1a9c(%rax) # current->pagefault_disable++
> movabs $0x123456789abcdef,%rcx # magic virtual address size
> cmp%rsi,%rcx
On Thu, 21 Nov 2024 at 13:40, Josh Poimboeuf wrote:
>
> The profile is showing futex_get_value_locked():
Ahh.
> That has several callers, so we can probably just use get_user() there?
Yeah, that's the simplest thing. That thing isn't even some inline
function, so the real cost is the call.
Tha
> On Fri, 15 Nov 2024 at 15:06, Josh Poimboeuf wrote:
> So I think the thing to do is
>
> (a) find out which __get_user() it is that matters so much for that load
>
> Do you have a profile somewhere?
>
> (b) convert them to use "unsafe_get_user()", with that whole
>
> if (can
On Sat, 16 Nov 2024 at 13:38, David Laight wrote:
>
> If __get_user() is the same as get_user() [..]
No, the problem is that it's the same from a performance angle (and
now it's actually slower), but some hacky code paths depend on
__get_user() not checking the address.
They then use that to rea
From: Linus Torvalds
> Sent: 16 November 2024 01:27
>
> On Fri, 15 Nov 2024 at 15:06, Josh Poimboeuf wrote:
> >
> > It's sad that __get_user() is now slower than get_user() on x86, it kind
> > of defeats the whole point!
>
> Well, honestly, we've been trying to get away from __get_user() and
> _
On Fri, Nov 08, 2024 at 05:12:53PM +, David Laight wrote:
> From: Josh Poimboeuf
> > On Mon, Oct 28, 2024 at 06:56:15PM -0700, Josh Poimboeuf wrote:
> > > The barrier_nospec() in 64-bit __get_user() is slow. Instead use
> > > pointer masking to force the user pointer to all 1's if a previous
>
On Fri, 15 Nov 2024 at 15:06, Josh Poimboeuf wrote:
>
> It's sad that __get_user() is now slower than get_user() on x86, it kind
> of defeats the whole point!
Well, honestly, we've been trying to get away from __get_user() and
__put_user() for a long long time.
With CLAC/STAC, it's been probably
From: Josh Poimboeuf
> Sent: 29 October 2024 03:28
>
> On Mon, Oct 28, 2024 at 06:56:15PM -0700, Josh Poimboeuf wrote:
> > The barrier_nospec() in 64-bit __get_user() is slow. Instead use
> > pointer masking to force the user pointer to all 1's if a previous
> > access_ok() mispredicted true for
On Mon, Oct 28, 2024 at 06:56:15PM -0700, Josh Poimboeuf wrote:
> The barrier_nospec() in 64-bit __get_user() is slow. Instead use
> pointer masking to force the user pointer to all 1's if a previous
> access_ok() mispredicted true for an invalid address.
Linus pointed out that __get_user() may b
The barrier_nospec() in 64-bit __get_user() is slow. Instead use
pointer masking to force the user pointer to all 1's if a previous
access_ok() mispredicted true for an invalid address.
Note that for safety on some AMD CPUs, this relies on recent commit
86e6b1547b3d ("x86: fix user address maskin
20 matches
Mail list logo
