Received: by 2002:a05:7412:31a9:b0:e2:908c:2ebd with SMTP id et41csp3870456rdb; Thu, 14 Sep 2023 05:28:06 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHq681PmGK0S6q2SyWXo3qxtOURBkEWcEXs9llokCDtHm3iMET0E+cfP6VSliHw4b7zG/pD X-Received: by 2002:a05:6a20:13cf:b0:153:6a8b:8f5d with SMTP id ho15-20020a056a2013cf00b001536a8b8f5dmr4467690pzc.23.1694694485644; Thu, 14 Sep 2023 05:28:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694694485; cv=none; d=google.com; s=arc-20160816; b=ZVJuou1TEvpAY6a2yxLwBo/Xrf13nceNUdLkp0VvjJicJHISuvfccusZpoxffqjsE8 P4Joq+VmFQAv+gj4zWErzRpScNvs+9YjQV0thKvRCO0IMMackCEQrOFV0FIXMtQEv1ta qkf+lcMOMCLAAA/9Lnb4ygXo3VMGTXWya4hllTj0fCfUc20DrXdWU7FF1NateBlSl5Gh AZcpzXQ0WUqVeHn0vfnwxUu7UzfPwOxx0k8KFSPEE5w+pSHgFoYArdRT+N5HU9U1EXT8 B/3NzqmDFJPBfPVTWoPhurXtUa4ISSJ2b2pUSvy5aqfX4RGy707Oi12MvAJSxAMbGyvu ykGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:references:in-reply-to:subject:cc:to:from :dkim-signature; bh=IKd/xoLaYMNT3G43ojUHtX33LcBflkrUDAX5TgQ89VQ=; fh=YbKARgxb7jAInoeUqYVskEDFZZFt7/yHuyJ5y6pINXc=; b=OfdpiVCk53d9z07GCrP6JOBDaYuu7bdBCjQ9KXA5Y7/u58uzMMnVxEWxy2blyudklc bQl7LvHdy5BSAoENa3VwELafy81uCeEiCqW3erlLPMO2yHnqOZE8ak3djHFt3XUnDw5h Dj8EjdjycL9+wWHbNKNun/R/ZAN3F7K/NjeVE/D1yQfHriKiYTOOS6CqlrfxKT/gO3HK iNeZ8gTp+gU386IkpAEALzNsrESafmCIkNgJZbhKNSaKRoFcs65VK2DWq99q9CPHnTI4 4ZiIUywTeyPZXWSZWzIzjXr8nGIMpYdgOBAkiws4S17njXsxADsjc1sz+8mCcdGiMzrN VaPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ellerman.id.au header.s=201909 header.b=rYiR5HRf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from pete.vger.email (pete.vger.email. [23.128.96.36]) by mx.google.com with ESMTPS id a39-20020a056a001d2700b0068fc2cbf489si1517340pfx.247.2023.09.14.05.28.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Sep 2023 05:28:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36; Authentication-Results: mx.google.com; dkim=pass header.i=@ellerman.id.au header.s=201909 header.b=rYiR5HRf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 092EB81A73C7; Thu, 14 Sep 2023 05:27:12 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238089AbjINM1K (ORCPT + 99 others); Thu, 14 Sep 2023 08:27:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59348 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237745AbjINM1J (ORCPT ); Thu, 14 Sep 2023 08:27:09 -0400 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6BF31FC9; Thu, 14 Sep 2023 05:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellerman.id.au; s=201909; t=1694694421; bh=IKd/xoLaYMNT3G43ojUHtX33LcBflkrUDAX5TgQ89VQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=rYiR5HRfpS/tMJ5vZ04WGHK5tqlEmN3zl7YBnuBIj4iDXvSjRcMk3Bm1xQR4G2xqA ch/6vWdPHmOC2BUMMk4XX30GKkFETwPb6UKi6HR3vSS9M+ZGF48pqFYfp4X0b6Xnoc 3IT8Xs1CRfVJWHkXJOg3XffMJXWhIzBrBfe0rLT/1FOwmVJNKXhzU+07wARKckah+G 1nYEufulJtii1DdLYzWI+dlftci66s6CJLfGerDALqoTxKf5zQo5DIOqkNkz913pHl hiwkYuo8iIaiLSkIq8iYXaa9BldBulkzz3WoyK+kyoqd71CY/sNwj3K8X+Pby7L5LJ Ni+zJOD6zygLg== Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4Rmc544Ldlz4wxN; Thu, 14 Sep 2023 22:26:48 +1000 (AEST) From: Michael Ellerman To: "Edgecombe, Rick P" , "Mehta, Sohil" , "linux-kernel@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-api@vger.kernel.org" Cc: "svens@linux.ibm.com" , "catalin.marinas@arm.com" , "schwab@linux-m68k.org" , "brgerst@gmail.com" , "alexander.shishkin@linux.intel.com" , "linux-perf-users@vger.kernel.org" , "x86@kernel.org" , "monstr@monstr.eu" , "borntraeger@linux.ibm.com" , "dave.hansen@linux.intel.com" , "christophe.leroy@csgroup.eu" , "mark.rutland@arm.com" , "glaubitz@physik.fu-berlin.de" , "dalias@libc.org" , "lukas.bulwahn@gmail.com" , "rdunlap@infradead.org" , "tglx@linutronix.de" , "hca@linux.ibm.com" , "linux@armlinux.org.uk" , "sparclinux@vger.kernel.org" , "arnd@arndb.de" , "linux-ia64@vger.kernel.org" , "ebiederm@xmission.com" , "Lutomirski, Andy" , "jolsa@kernel.org" , "linux-parisc@vger.kernel.org" , "akpm@linux-foundation.org" , "linux-sh@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "geert@linux-m68k.org" , "hpa@zytor.com" , "James.Bottomley@HansenPartnership.com" , "peterz@infradead.org" , "ink@jurassic.park.msu.ru" , "linux-m68k@lists.linux-m68k.org" , "tsbogend@alpha.franken.de" , "broonie@kernel.org" , "Hunter, Adrian" , "acme@kernel.org" , "ysato@users.sourceforge.jp" , "deller@gmx.de" , "debug@rivosinc.com" , "rmclure@linux.ibm.com" , "gor@linux.ibm.com" , "slyich@gmail.com" , "npiggin@gmail.com" , "agordeev@linux.ibm.com" , "chris@zankel.net" , "mingo@redhat.com" , "linux-mips@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "mattst88@gmail.com" , "linux-s390@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "jcmvbkbc@gmail.com" , "bp@alien8.de" , "richard.henderson@linaro.org" , "irogers@google.com" , "namhyung@kernel.org" , "will@kernel.org" , "davem@davemloft.net" Subject: Re: [PATCH 2/2] arch: Reserve map_shadow_stack() syscall number for all architectures In-Reply-To: <8b7106881fa227a64b4e951c6b9240a7126ac4a2.camel@intel.com> References: <20230911180210.1060504-1-sohil.mehta@intel.com> <20230911180210.1060504-3-sohil.mehta@intel.com> <8b7106881fa227a64b4e951c6b9240a7126ac4a2.camel@intel.com> Date: Thu, 14 Sep 2023 22:26:47 +1000 Message-ID: <871qf17xfc.fsf@mail.lhotse> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Thu, 14 Sep 2023 05:27:12 -0700 (PDT) X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email "Edgecombe, Rick P" writes: > On Mon, 2023-09-11 at 18:02 +0000, Sohil Mehta wrote: >> diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl >> b/arch/powerpc/kernel/syscalls/syscall.tbl >> index 20e50586e8a2..2767b8a42636 100644 >> --- a/arch/powerpc/kernel/syscalls/syscall.tbl >> +++ b/arch/powerpc/kernel/syscalls/syscall.tbl >> @@ -539,3 +539,4 @@ >> =C2=A0450=C2=A0=C2=A0=C2=A0=C2=A0nospu=C2=A0=C2=A0=C2=A0set_mempolicy_ho= me_node=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0sys_set_mempol= icy_hom >> e_node >> =C2=A0451=C2=A0=C2=A0=C2=A0=C2=A0common=C2=A0=C2=A0cachestat=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0sys_cachestat >> =C2=A0452=C2=A0=C2=A0=C2=A0=C2=A0common=C2=A0=C2=A0fchmodat2=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0sys_fchmodat2 >> +453=C2=A0=C2=A0=C2=A0=C2=A0common=C2=A0=C2=A0map_shadow_stack=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0sys_map_shadow_stack > > I noticed in powerpc, the not implemented syscalls are manually mapped > to sys_ni_syscall. It also has some special extra sys_ni_syscall() > implementation bits to handle both ARCH_HAS_SYSCALL_WRAPPER and > !ARCH_HAS_SYSCALL_WRAPPER. So wondering if it might need special > treatment. Did you see those parts? I don't think it needs any special treatment. It's processed by the same script as other arches (scripts/syscalltbl.sh). So if there's no compat or native entry it will default to sys_ni_syscall. I think it's just habit/historical that we always spell out sys_ni_syscall. cheers