linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: David Miller <davem@davemloft.net>
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
Subject: Re: [PATCH v2 3/4] sparc: add system call table generation support
Date: Mon, 5 Nov 2018 11:48:43 +0100	[thread overview]
Message-ID: <CAK8P3a0XOzuMxv5wJpd=jhronFJQ=PwCZ58VgxSkL_sSPV+CZQ@mail.gmail.com> (raw)
In-Reply-To: <20181101.133315.47887636039827313.davem@davemloft.net>

On 11/1/18, David Miller <davem@davemloft.net> wrote:
> From: Firoz Khan <firoz.khan@linaro.org>
> 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

  parent reply	other threads:[~2018-11-05 10:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-01 13:53 [PATCH v2 0/4] sparc: system call table generation support Firoz Khan
2018-11-01 13:53 ` [PATCH v2 1/4] sparc: move __IGNORE* entries to non uapi header Firoz Khan
2018-11-01 13:53 ` [PATCH v2 2/4] sparc: add __NR_syscalls along with NR_syscalls Firoz Khan
2018-11-01 13:53 ` [PATCH v2 3/4] sparc: add system call table generation support Firoz Khan
2018-11-01 20:33   ` David Miller
2018-11-02  5:39     ` Firoz Khan
2018-11-02  6:04       ` David Miller
2018-11-05 10:48     ` Arnd Bergmann [this message]
2018-11-06  4:28       ` David Miller
2018-11-01 13:53 ` [PATCH v2 4/4] sparc: generate uapi header and system call table files Firoz Khan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK8P3a0XOzuMxv5wJpd=jhronFJQ=PwCZ58VgxSkL_sSPV+CZQ@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=davem@davemloft.net \
    --cc=deepa.kernel@gmail.com \
    --cc=firoz.khan@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcin.juszkiewicz@linaro.org \
    --cc=pombredanne@nexb.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=y2038@lists.linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).