On Thu, Sep 14, 2017 at 10:46:37PM -0700, h...@zytor.com wrote: > On September 14, 2017 10:31:55 PM PDT, Ingo Molnar <mi...@kernel.org> wrote: > > > >* Andy Lutomirski <l...@kernel.org> wrote: > > > >> >> > diff --git a/arch/x86/entry/entry_64.S > >b/arch/x86/entry/entry_64.S > >> >> > index 4916725..3bab6af 100644 > >> >> > --- a/arch/x86/entry/entry_64.S > >> >> > +++ b/arch/x86/entry/entry_64.S > >> >> > @@ -185,12 +185,10 @@ entry_SYSCALL_64_fastpath: > >> >> > */ > >> >> > TRACE_IRQS_ON > >> >> > ENABLE_INTERRUPTS(CLBR_NONE) > >> >> > -#if __SYSCALL_MASK == ~0 > >> >> > - cmpq $__NR_syscall_max, %rax > >> >> > -#else > >> >> > - andl $__SYSCALL_MASK, %eax > >> >> > - cmpl $__NR_syscall_max, %eax > >> >> > +#if __SYSCALL_MASK != ~0 > >> >> > + andq $__SYSCALL_MASK, %rax > >> >> > #endif > >> >> > + cmpq $__NR_syscall_max, %rax > >> >> > >> >> I don't know much about x32 userspace, but there's an argument > >that > >> >> the high bits *should* be masked off if the x32 bit is set. > >> > > >> > Why? > >> > >> Because it always worked that way. > >> > >> That being said, I'd be okay with applying your patch and seeing > >> whether anything breaks. Ingo? > > > >So I believe this was introduced with x32 as a 'fresh, modern syscall > >ABI' > >behavioral aspect, because we wanted to protect the overly complex > >syscall entry > >code from 'weird' input values. IIRC there was an old bug where we'd > >overflow the > >syscall table in certain circumstances ... > > > >But our new, redesigned entry code is a lot less complex, a lot more > >readable and > >a lot more maintainable (not to mention a lot more robust), so if > >invalid RAX > >values with high bits set get reliably turned into -ENOSYS or such then > >I'd not > >mind the patch per se either, as a general consistency improvement. > > > >Of course if something in x32 user-land breaks then this turns into an > >ABI and we > >have to reintroduce this aspect, as a quirk :-/ > > > >It should also improve x32 syscall performance a tiny bit, right? So > >might be > >worth a try on various grounds. > > > >( Another future advantage would be that _maybe_ we could use the high > >RAX > >component as an extra (64-bit only) special argument of sorts. Not that > >I can > > think of any such use right now. ) > > > >Thanks, > > > > Ingo > > x32 should be sharing the native 64-but entry code, by design. > We have had the latter mask the upper 32 bits,
There must be some misunderstanding on your side: the clearing of the upper 32 bits of 64-bit syscall numbers currently happens if and only if fastpath and CONFIG_X86_X32_ABI is enabled. -- ldv
signature.asc
Description: PGP signature