Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751845AbdIQQp2 (ORCPT ); Sun, 17 Sep 2017 12:45:28 -0400 Received: from vmicros1.altlinux.org ([194.107.17.57]:38798 "EHLO vmicros1.altlinux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751651AbdIQQpJ (ORCPT ); Sun, 17 Sep 2017 12:45:09 -0400 Date: Sun, 17 Sep 2017 19:45:07 +0300 From: "Dmitry V. Levin" To: hpa@zytor.com Cc: Ingo Molnar , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , X86 ML , Oleg Nesterov , Eugene Syromyatnikov , linux-kernel@vger.kernel.org, Linus Torvalds , Peter Zijlstra , Andrew Morton , "Dmitry V. Levin" Subject: Re: [PATCH] x86/asm/64: do not clear high 32 bits of syscall number when CONFIG_X86_X32=y Message-ID: <20170917164506.GA28036@altlinux.org> Mail-Followup-To: hpa@zytor.com, Ingo Molnar , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , X86 ML , Oleg Nesterov , Eugene Syromyatnikov , linux-kernel@vger.kernel.org, Linus Torvalds , Peter Zijlstra , Andrew Morton References: <20170912225756.GA19364@altlinux.org> <20170914213316.GB17533@altlinux.org> <20170915053155.f336vlejdql23zxu@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3791 Lines: 108 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 14, 2017 at 10:46:37PM -0700, hpa@zytor.com wrote: > On September 14, 2017 10:31:55 PM PDT, Ingo Molnar wro= te: > > > >* Andy Lutomirski 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 =3D=3D ~0 > >> >> > - cmpq $__NR_syscall_max, %rax > >> >> > -#else > >> >> > - andl $__SYSCALL_MASK, %eax > >> >> > - cmpl $__NR_syscall_max, %eax > >> >> > +#if __SYSCALL_MASK !=3D ~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? > >>=20 > >> Because it always worked that way. > >>=20 > >> 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'=20 > >behavioral aspect, because we wanted to protect the overly complex > >syscall entry=20 > >code from 'weird' input values. IIRC there was an old bug where we'd > >overflow the=20 > >syscall table in certain circumstances ... > > > >But our new, redesigned entry code is a lot less complex, a lot more > >readable and=20 > >a lot more maintainable (not to mention a lot more robust), so if > >invalid RAX=20 > >values with high bits set get reliably turned into -ENOSYS or such then > >I'd not=20 > >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=20 > >have to reintroduce this aspect, as a quirk :-/ > > > >It should also improve x32 syscall performance a tiny bit, right? So > >might be=20 > >worth a try on various grounds. > > > >( Another future advantage would be that _maybe_ we could use the high > >RAX=20 > >component as an extra (64-bit only) special argument of sorts. Not that > >I can=20 > > think of any such use right now. ) > > > >Thanks, > > > > Ingo >=20 > 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. --=20 ldv --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZvqaSAAoJEAVFT+BVnCUIneAQAN+gWLsCuiDhYGSloBaXoyly Ad33F5rsL7w/B9cI5jlzVDv217dxOAjzdJGj9SeuckXgvB6PuF3EkkfnfWAR7TkA sgUTylCvC3grbD9gYA8kzOwaZ/v3ZFD5AS4V9E5rWIgqbzjJkW1rOuf3AzFUtUGf MDlZtGiOKiO3IFiWB76PikxeUCyj2sV85IQrzkx/qE/N3ShDNZ01q/YJQhNVvcYn oOSad8NJJHyx1THelOxOBM8peSA3jixu5iJsFipMPuUT+dR6HJ6tdBPyg0QiXyRA 5PE6rASeGUn6ZtFFURm16lGE+16HSB6Wmx8xic/dCmZlkgtCn3oWPOVki6JQ/VLw 9AKsOWwLkGpNEuyBDXBhKmxM7PqiSNG0lyGdeuH5Y0BZwbM4FEIX/Jksn6NvGDGH kTjivXAPX84X/cp4FYunhIC9meOBxxctpamNY4CkS3d93G769aLELPsf8FQ84LkU CUZAFMlA6536Q70riSBV/aosZjo9JjPqqlSq7JxnKZ2bKHJKjuCIeLWSLk0nqKVO akCIeX8f6iVsOlQmHTGoeCyb4Jcjfv1TG9M/ab7KsLWerVHZCiL2oorpZGi6Jlmn K6qQ4B78ODXYvKq7CctqbYSwmvF/DNzbJGSsuONFQFgz9Syixz90jbJBO+yBr/Hh /uiv8p2rSMnXedXLI0Tb =RXjH -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK--