Message-Id: <158d8c88-0b39-46f2-824a-7b3a52f4ee0a@app.fastmail.com>
Date: Fri, 19 Jul 2024 16:24:38 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Linus Torvalds" <torvalds@...ux-foundation.org>,
 "Stephen Rothwell" <sfr@...b.auug.org.au>
Cc: "Masami Hiramatsu" <mhiramat@...nel.org>,
 "Andrii Nakryiko" <andrii@...nel.org>,
 "Jeff Johnson" <quic_jjohnson@...cinc.com>, "Jiri Olsa" <jolsa@...nel.org>,
 "Steven Rostedt" <rostedt@...dmis.org>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] probes: Updates for v6.11

On Fri, Jul 19, 2024, at 02:49, Linus Torvalds wrote:
> On Thu, 18 Jul 2024 at 17:28, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> There are system calls that are architecture-specific (the whole vdso
> thing), and nothing is ever going to change that.
>
> Others may not be as fundamentally tied to certain architectures -
> like this uprobes thing - but will simply be introduced at different
> times because they still need possibly a lot of architecture support.
>
> So considering that it was added this merge window, and already is
> showing all these issues before the merge window is even over, I'm not
> at all convinced "scripts/syscall.tbl" has a future.
>
> Now, I do think we should strive to unify the system call table
> generation under one syntax. I don't think *that* is a bad idea.
>
> But I'm not AT ALL convinced we should strive to unify the numbering,
> and do it in one file.

The unified syntax is all that is new though, the unified numbering
is what we've been doing since the time32 syscalls (403+) in 2019.

The unified table across all /new/ architectures has been in place
since e64a1617eca3 ("asm-generic: add a generic unistd.h") back
in 2009, so the eight newest architectures, plus a few that have
come and gone again, have been sharing the same numbers for
the past 15 years.

> In fact, I think that the numbering should not exist at all in that
> "unified table syntax", because the number itself is causing problems.
>
> That whole "the numbers themselves are a problem" is not a new issue,
> we've seen all these silly renumbering issues forever, just look at
> something like this:
>
>   git log --oneline --merges --cc arch/x86/entry/syscalls/syscall_64.tbl
>
> and that's with people often _trying_ to work together.  So I think
> 'scripts/syscall.tbl' is actively detrimental, because it introduces
> *new* problems, and it doesn't actually solve that *old* problem.
>
> So I think this needs to be re-visited.

The syscall.tbl file itself is just a replacement for
include/uapi/asm-generic/unistd.h, which I would like to remove
in the next step, it's already unused.

I was planning as one of the future steps to move numbers
403 through 467 into a file that is actually shared, to make
it easier to coordinate the addition of system calls:
any addition would only get added once instead of 19 times.
I have not tried implementing this yet, the open questions
here are how to handle alpha with its different numbers
(offset by 110) and x32 with the preassigned numbers 512-547.

This has always been something that others have asked me
for since we started using the syscall.tbl format on most
architectures, but I don't actually care about this part too
much, compared to other things I would like to implement
based on the syscall.tbl format like a machine-readable
ABI description that contains both the syscall numbers and
the argument types.

> One possible model might be:
>
>  - remove the numbering from the syscall.tbl (because the numbers
> _are_ going to be different)
>
>  - make it really easy to add actual generic new system calls in one
> place, for when the system call is NOT something that needs
> architecture-specific trampolines and stuff
>
>  - make the common infrastructure generate the numbers
>
> because I think the current model of "let's share a table with
> numbers" is already dead in the water before we have even completed a
> single merge window with it.
>
> Other ideas? Arnd?

I don't think we have to abandon the common numbering now, given
that this is the part that has mostly worked out fine, with
architecture specific syscalls being really rare in practice.
We have been dealing with them already for 15 years, and this
hasn't really changed with my recent patches either.

a) numbers 244 through 259 are reserved for architecture specific
   calls. A typical example of this is "cacheflush", which is
   used on four architectures. Architectures with a custom
   syscall.tlb file can instead use the available numbers below
   403 where needed.

b) clone3 is still missing on four architectures but should be
   implemented there. This used to require defining
   __ARCH_WANT_SYS_CLONE3 on all architectures, but I've turned
   it around now so architectures that are missing it instead
   define __ARCH_BROKEN_SYS_CLONE3.

c) memfd_secret is only used only on x86, arm64, riscv and s390.
   With the new table format, this now requires adding the keyword
   in arch*/kernel/Makefile.syscalls, e.g. for riscv as
   syscall_abis_32 += riscv memfd_secret
   syscall_abis_64 += riscv newstat rlimit memfd_secret

I discussed all three methods with Jiri when looking at his
uretprobe patches. I recommended using b) at the time since
I wanted to avoid the extra keyword from c), but it sounds
like you would be happier with a). If you like, I can send
a patch to move it to number 335 for x86, or you can move
it yourself if that addresses the specific problem with
the uretprobe.

      Arnd

Powered by blists - more mailing lists