Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp401703imu; Mon, 5 Nov 2018 02:49:29 -0800 (PST) X-Google-Smtp-Source: AJdET5e7yQftJFw64iP2JnF8ylvUtM43wg0RrXo8VJGce9F4SE1xB7LxpfETuLYmxfPe6lcu8DAE X-Received: by 2002:a63:6906:: with SMTP id e6mr19296868pgc.144.1541414969849; Mon, 05 Nov 2018 02:49:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541414969; cv=none; d=google.com; s=arc-20160816; b=RwxDLxeBZNmCqcYjlkI0ZqQ72sFV8m9Tf/5xBgBopwl2vUq+UlePIW2NHCM1JaBKWg WOSpBvn/rXwB0o09Y7MQhtJ8QqzBamkC3e3I+TXGkNoCmf//PP+JF4UshaHUySrhpmq2 KU4v8VOpCaPJvTSQX1kE+MXv/r91+v1ugnpipsCvGRCpNrb+kpzCw4ndAVIQmE+kU37o PfCcTOipPHYLFxZh6eTXLfvHXrz7UyAlffxVGkpZggzmB4+IhxSnUhlq/zioJ7efHT05 zLr5w1S72UpwBTbUcXmVTknNZ72RVdOQg1GsL4Z97QXjRr+pOZSiKNqiNf43+WEAy+8D ZOhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature; bh=VGy21yXs7PqriFmcuGpTYyN0BAsMXNv4ABiMrfybyEA=; b=G6qnAZYRmWCAa9XHK5soU41PZIu93WW5zbLQTaVCNQe0ujP9q2Uondg1YZ+0KwVR8E IRB6ja3SOCXsR7di4sci2HlMExShYkonyS9I8EDVPznELWmMKcqchSk9RJCxY1YDpoLj 1FYXcBvivYYOWn3gAbZ7wX47npCfS+gCf81zhN4bNIfMSTAaCl8js/hFETkUVh0NdQih px+Pwvro7rCbDRkYZpgAiL7rCVUNwCRhDPlbb+UfWIAGJYQkrqGqWgYwu3l+qcEzKNRL SGNK6GYFp9xP35mnSy8i7TJ3pXH8zYHmYo05YV7M/KWQZssGSw8//39w79uu0tqBTBvs AxVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=mf3ngnmA; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 9-v6si43547198pgn.512.2018.11.05.02.49.14; Mon, 05 Nov 2018 02:49:29 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=mf3ngnmA; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728947AbeKEUHv (ORCPT + 99 others); Mon, 5 Nov 2018 15:07:51 -0500 Received: from mail-qk1-f194.google.com ([209.85.222.194]:35088 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726255AbeKEUHv (ORCPT ); Mon, 5 Nov 2018 15:07:51 -0500 Received: by mail-qk1-f194.google.com with SMTP id v68-v6so13799000qka.2; Mon, 05 Nov 2018 02:48:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=VGy21yXs7PqriFmcuGpTYyN0BAsMXNv4ABiMrfybyEA=; b=mf3ngnmATrKKwFeuTibz6HaKqRIVUINfgzLlQTGqgaU0EN8Nalt+Yr73vg33MFKibw YPLSA9yH9NlCJGN4Lc2vq4FrBP0ZL3GS75VzZimcu+xgZsaSQSEiC1hv/PflKSRQ/tj/ w9sV2uH5EcMSc1E8vKlhn6zYypcYQP5/sz89tz+c/57F9ffyffzK7iAt5w/uBHMBFCjO H2fKtlF+CZaJos2GS196Jgbbi0n3k/q8Se5xvtgUrXPFKb0toFUOerLUiAHyS50QThmU +4l8Ptmter8a/xf+O7QuGwnSyb9FErjrTkduB3NU0ikEbvdBr2IpEr0nT8OJ4IH9ledC 15sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=VGy21yXs7PqriFmcuGpTYyN0BAsMXNv4ABiMrfybyEA=; b=hhpvN12hn/eZUOK5DbtH4QW+upqbY4e7Y36fy9+BTKutvoMAYT62kKWCRqqSFlHFjj 8SExvDdRJIIL+8Ax8L0zmZFUYNF/rqgue1ncRyq3j+WWo28FgxzTdrkW/t/20mdzkn40 PHLNUSCRBEn1D8PzIUDn57K9UrmJ5U6qNN5A2MNpKYUeLyEKHbV4DvNk4zFM75TNakgT 2JlYa+7rhBcs1wC/Rt3eou2VWQgDBVFoI+SVQMBcBiVUaeUQb7pI0BtY+RgnpJnFgU79 MdT1w3ZkYenxCvdhKkRRg1pSNXYQZZs6BKZFdlALxuB0wMrtEs4lg43ZEEwkFzZJQs+N TM4Q== X-Gm-Message-State: AGRZ1gLs2dgTe+jrEbfDmz+FdiWDHQaLXse5sfGMgM1jJj1jY1EcecXt wpN3SkFlwgDSyrB7sZkrWaKxBeOVJEPxh9S/VTc= X-Received: by 2002:aed:35c5:: with SMTP id d5mr20334936qte.212.1541414924152; Mon, 05 Nov 2018 02:48:44 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a0c:9881:0:0:0:0:0 with HTTP; Mon, 5 Nov 2018 02:48:43 -0800 (PST) In-Reply-To: <20181101.133315.47887636039827313.davem@davemloft.net> References: <1541080391-3890-1-git-send-email-firoz.khan@linaro.org> <1541080391-3890-4-git-send-email-firoz.khan@linaro.org> <20181101.133315.47887636039827313.davem@davemloft.net> From: Arnd Bergmann Date: Mon, 5 Nov 2018 11:48:43 +0100 X-Google-Sender-Auth: YLE8SQ_d1M_BdaD0kmnQ_yRDsMk Message-ID: Subject: Re: [PATCH v2 3/4] sparc: add system call table generation support To: David Miller Cc: firoz.khan@linaro.org, sparclinux@vger.kernel.org, gregkh@linuxfoundation.org, pombredanne@nexb.com, tglx@linutronix.de, kstewart@linuxfoundation.org, y2038@lists.linaro.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, deepa.kernel@gmail.com, marcin.juszkiewicz@linaro.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/1/18, David Miller wrote: > From: Firoz Khan > Date: Thu, 1 Nov 2018 19:23:10 +0530 > >> +141 common getpeername sys_getpeername sys_nis_syscall > ... >> +150 common getsockname sys_getsockname sys_nis_syscall > > The sys_nis_syscall in these two entries is incorrect, see the patch > below. > > One of my worst fears about this change has been realized, that > instead of helping us find problems, it is so automated to the point > that it fails to question issues like this. > > If sys_nis_syscall for the compat syscall shows up in a situation where the > native 32-bit syscall does have an entry, that's a BUG and the script > should > point this out so that the bug can be fixed. I see this as a multi-step process. Unfortunately, some architectures have multiple issues in their system call tables, most importantly the ones that include system call numbers on some architectures but have had them removed when the implementation got removed. The sparc sys_nis_syscall is another such issue: we don't have anything like that on other architectures, so I think we should either move it to kernel/sys_ni.c for everyone, or use the normal sys_ni_syscall(). Then there is inconsistency between the set of system calls per architecture, e.g. some have both socketcall()/ipc() and the individual socket syscalls from those multiplexors, some only have one of the two sets. Here, I think we may want to move to the separate system calls on all architectures and only keep the multiplexors for backwards compatibility. A future glibc may then remove the support for socketcall() and ipc() once they require linux-5.x or higher and always have the separate calls. However, for all of those, I want the /format/ of the tables to be consistent so we can create the tooling around it to find and fix the issues. The work that Firoz is doing for now just makes sure that the /contents/ of the tables don't change at all, which is hard enough to do (the current version gets it all right afaict, but the previous versions missed some details). Arnd