Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sat, 15 May 2021 10:42:48 -0700
User-Agent: K-9 Mail for Android
In-Reply-To: <f2e4c3c3-08c3-eae1-803a-aa85d7e75ca0@kernel.org>
References: <20210515011015.2707542-1-hpa@zytor.com> <20210515011015.2707542-5-hpa@zytor.com> <f2e4c3c3-08c3-eae1-803a-aa85d7e75ca0@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PATCH v3 4/4] x86/syscall: use int everywhere for system call numbers
To:     Andy Lutomirski <luto@kernel.org>, Ingo Molnar <mingo@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Borislav Petkov <bp@alien8.de>
CC:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
From:   "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <C1CB9B19-185F-469E-A59C-ECAA95AAC279@zytor.com>
Precedence: bulk

Answer: I don't think it is a good idea to have the system can table offset=
 =2E=2E=2E it seems like an unnecessary debugging headache=2E

On May 15, 2021 8:37:12 AM PDT, Andy Lutomirski <luto@kernel=2Eorg> wrote:
>On 5/14/21 6:10 PM, H=2E Peter Anvin wrote:
>> From: "H=2E Peter Anvin (Intel)" <hpa@zytor=2Ecom>
>>=20
>> System call numbers are defined as int, so use int everywhere for
>> system call numbers=2E This patch is strictly a cleanup; it should not
>> change anything user visible; all ABI changes have been done in the
>> preceeding patches=2E
>>=20
>> Signed-off-by: H=2E Peter Anvin (Intel) <hpa@zytor=2Ecom>
>> ---
>>  arch/x86/entry/common=2Ec        | 93
>++++++++++++++++++++++++----------
>>  arch/x86/include/asm/syscall=2Eh |  2 +-
>>  2 files changed, 66 insertions(+), 29 deletions(-)
>>=20
>> diff --git a/arch/x86/entry/common=2Ec b/arch/x86/entry/common=2Ec
>> index f51bc17262db=2E=2E714804f0970c 100644
>> --- a/arch/x86/entry/common=2Ec
>> +++ b/arch/x86/entry/common=2Ec
>> @@ -36,49 +36,87 @@
>>  #include <asm/irq_stack=2Eh>
>> =20
>>  #ifdef CONFIG_X86_64
>> -__visible noinstr void do_syscall_64(struct pt_regs *regs, unsigned
>long nr)
>> +
>> +static __always_inline bool do_syscall_x64(struct pt_regs *regs, int
>nr)
>> +{
>> +	/*
>> +	 * Convert negative numbers to very high and thus out of range
>> +	 * numbers for comparisons=2E Use unsigned long to slightly
>> +	 * improve the array_index_nospec() generated code=2E
>> +	 */
>> +	unsigned long unr =3D nr;
>> +
>> +	if (likely(unr < NR_syscalls)) {
>> +		unr =3D array_index_nospec(unr, NR_syscalls);
>> +		regs->ax =3D sys_call_table[unr](regs);
>> +		return true;
>> +	}
>> +	return false;
>> +}
>
>How much do you like micro-optimization?  You could be silly^Wclever
>and
>add a new syscall handler:
>
>long skip_syscall(struct pt_regs *regs)
>{
>	return regs->ax;
>}
>
>and prepend this to the syscall tables -- it would be a sort-of-real
>syscall -1=2E  Then the call sequence becomes:
>
>int adjusted_nr =3D nr + 1 (or nr - x32bit + 1);
>
>if (likely(nr < NR_adjusted_syscalls)) {
>   unr =3D array_index_nospec=2E=2E=2E;
>   regs->ax =3D sys_call_table[unr](regs);  /* might be a no-op! */
>} else {
>    regs->ax =3D -ENOSYS;
>}
>
>which removes a branch from the fast path=2E

--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E