linux-kernel - Re: linux-next: manual merge of the vfs-brauner tree with the asm-generic tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <918695c2-0fb0-4439-836b-572836f66a26@app.fastmail.com>
Date: Tue, 09 Jul 2024 16:26:00 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Jiri Olsa" <olsajiri@...il.com>
Cc: "Stephen Rothwell" <sfr@...b.auug.org.au>,
 "Christian Brauner" <brauner@...nel.org>,
 Christian Göttsche <cgzones@...glemail.com>,
 "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
 linux-next <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the vfs-brauner tree with the asm-generic tree

On Tue, Jul 9, 2024, at 15:17, Jiri Olsa wrote:
> On Tue, Jul 09, 2024 at 02:58:06PM +0200, Arnd Bergmann wrote:
>> 
>> If this cannot be used on any other architectures, I would
>> suggest adding it to the architecture specific list instead,
>> probably number #335, which is unused on x86-64.
>> 
>> I was under the assumption that this would theoretically be
>> useful for non-x86 architectures in the future, in which
>
> yes, at the moment uretprobe is implemented on x86_64 only,
> but it could be perhaps implemented on other archs in future
>
>> case you should reserve the same syscall number everywhere
>
> hum, is that necessary? I don't mind, but I don't see why it
> should be the same number on another archs?

All new system calls have the same number across architectures
since number 403 for consistency (except arch/alpha, which
uses 110 more than the others).

Linus did comment the other day that he did not think we
need to actually assign the numbers when the system calls
are unlikely to actually be implemented on most architectures,
but it would be good to at least add a comment in each
syscall.tbl file to say which syscall the number is going
to be used for if it does get assigned.

     Arnd