Thread (8 messages) 8 messages, 2 authors, 2024-07-03

Re: [PATCH v20 3/5] arch: allocate vgetrandom_alloc() syscall number

From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: 2024-07-03 19:04:46
Also in: linux-crypto, linux-patches, lkml

Hi Arnd,

On Wed, Jul 3, 2024 at 8:59 PM Arnd Bergmann [off-list ref] wrote:
On Wed, Jul 3, 2024, at 20:31, Jason A. Donenfeld wrote:
quoted
Add vgetrandom_alloc() as syscall 463 (or 573 on alpha) by adding it to
all of the various syscall.tbl and unistd.h files.

Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
I checked that the system calls are all hooked up correctly
across all architectures:

Acked-by: Arnd Bergmann <arnd@arndb.de>
Thanks.
Unfortunately we now have three syscalls scheduled for
the number 463, the other ones being uretprobe (only
for arc, arm64, csky, hexagon, loongarch, nios2, openrisc,
riscv and x86 for some reason) and setxattrat (on
all architectures).

It would be nice if you could all coordinate on this to
pick unique numbers.
Stephen and I were just talking about this when looking at the linux-next merge.

Dibs on 463! Just kidding.

There's going to be merge conflicts anyway, due to the __NR_syscalls
counter changing. So I figured this is something Linus typically just
handles based on what order he merges things in. But I actually don't
know. What's the best way to handle this?

Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help