Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1774488pxj; Sun, 16 May 2021 03:55:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyxIB89u9P+9n1HXGsvjYBiCQMIIfqZcR2tASq6xZHIo3bfQmrHg5I21S0zEndOInf7iaSl X-Received: by 2002:a17:906:33d6:: with SMTP id w22mr8423063eja.222.1621162533214; Sun, 16 May 2021 03:55:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621162533; cv=none; d=google.com; s=arc-20160816; b=bWFFkhWAPM51Bc0eKNIyNBYeF7CH358yrr42kd3vMbxixTOyFMoXB96kxq3EP7ZnLx fNMOBA47O5/IyDp71TKDYP2jmDu7t9/q+qAbXt14cAsy2p2RKcKdu3HEmRksa99aghGz E8JHQRZIzaRErSrfIKYtxaT5fw4iK9HZ80W1j8a6kRb/On626r/xkmHzfxhNxR8W/4e+ eXBxDskZaoJcIddoKXnuvKZCW3P/2Xm0E8qM4jjLG82LQz8Xr3QiQNwR8BLGla+RFhfR EUDjci7a/oGLJmmJlXp0hVqewRkX8u2lORsuFz/LjdkVmSvMCNZhecx3IBL7oIIJdAUi 0aQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:from:cc:to:subject :content-transfer-encoding:mime-version:references:in-reply-to :user-agent:date:dkim-signature:dkim-filter; bh=ECT3h7vQpngfn25c/QoKWtsYhzETuPXg6kMhVwqDoE0=; b=ySYKTri6Q4Cqv/QXR4IxjbA7l1B5sVvCvgPIGL+XGp9BD+Q2O0V1E2DKFxllXGQNM6 YHrpO7rFKDsZrSi7ClpDQQ/6duXkHV+RuvJOftP37BfvT0TEBmJKiuWpbIMdrJd88jhf Dl1DqZ2ZKh3R2kRhyN711SprO2XT+pxERgEvrLM4izLsaZQk220fI1QoHfsYnnykRS3s iJwAyaIs9ZXdnszweo4efiWNi3UBTw/fNbnl5dwzqxucqbw1KMo38tb+RYYoIyLfrcg/ qTQsgjdcGX2ZJrTpXnHMRCdKZtwENDRaXg9LM3EFbiKbiUU9/1MJcfo1nLLbOOE2gHBv aOng== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@zytor.com header.s=2021042801 header.b=crxNoHPw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=zytor.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f26si10604226ejf.128.2021.05.16.03.55.09; Sun, 16 May 2021 03:55:33 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=fail header.i=@zytor.com header.s=2021042801 header.b=crxNoHPw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=zytor.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235058AbhEOVIm (ORCPT + 99 others); Sat, 15 May 2021 17:08:42 -0400 Received: from terminus.zytor.com ([198.137.202.136]:33025 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229938AbhEOVIl (ORCPT ); Sat, 15 May 2021 17:08:41 -0400 Received: from [IPv6:2601:646:8602:8be1:e512:4e99:5d16:dcc6] ([IPv6:2601:646:8602:8be1:e512:4e99:5d16:dcc6]) (authenticated bits=0) by mail.zytor.com (8.16.1/8.15.2) with ESMTPSA id 14FL7ANU3374296 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 15 May 2021 14:07:12 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 14FL7ANU3374296 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2021042801; t=1621112832; bh=ECT3h7vQpngfn25c/QoKWtsYhzETuPXg6kMhVwqDoE0=; h=Date:In-Reply-To:References:Subject:To:CC:From:From; b=crxNoHPwLXC/E/Tx9ql6mZSrnh+eZC8qeB1jM/DoPxaFfZSlQNtydPnIdVCgOEOqM h9q+p+pLFJgFssFmIeSbgIyl5DckJ2ZeMIZre+pnC9wH7krpTTd0aVlqvQpbOSCCA7 Ech/YmYujBzf0iWn6wSXZE92KxIbb4mhCrtAg76EYXebQHoUdKBVG6IwgvAf2N3Ec4 FuAlI1iFpRC0UyqXp9vPCcp+mSmQPsjUmsmdxQJrQybJNF4t7hIih+IcAnz99eH4Sq M3zBTVByBoy/Tq+/Orfx1W/KeWYCq+E6Ylp6KSEQD9/zkQZ7UAg0FhRHDKHhhoujvZ GmmOHWoksdgpg== Date: Sat, 15 May 2021 14:07:01 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <2ebf1bac-93c1-4b7f-add4-4ede3c149b52@www.fastmail.com> References: <20210515011015.2707542-1-hpa@zytor.com> <20210515011015.2707542-5-hpa@zytor.com> <2ebf1bac-93c1-4b7f-add4-4ede3c149b52@www.fastmail.com> 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 , Ingo Molnar , Thomas Gleixner , Borislav Petkov CC: Linux Kernel Mailing List From: "H. Peter Anvin" Message-ID: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Pretty soon you'll have the whole entry code rewritten back into assembly = =F0=9F=98=86 On May 15, 2021 11:48:22 AM PDT, Andy Lutomirski wrote= : > > >On Sat, May 15, 2021, at 10:42 AM, H=2E Peter Anvin wrote: >> 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 > >Emit it in asm: > >table_minus_one: > =2Equad not_a_syscall >table: > (real table here) > >/me runs=2E > > > >>=20 >> On May 15, 2021 8:37:12 AM PDT, Andy Lutomirski > wrote: >> >On 5/14/21 6:10 PM, H=2E Peter Anvin wrote: >> >> From: "H=2E Peter Anvin (Intel)" > >> >>=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) > >> >> --- >> >> 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 >> >> =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 >> --=20 >> Sent from my Android device with K-9 Mail=2E Please excuse my brevity= =2E >>=20 --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E