Hi Arnd, On Wed, Jul 3, 2024 at 8:59 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Wed, Jul 3, 2024, at 20:31, Jason A. Donenfeld wrote: > > 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@xxxxxxxxxxxxxx> > > Signed-off-by: Jason A. Donenfeld <Jason@xxxxxxxxx> > > I checked that the system calls are all hooked up correctly > across all architectures: > > Acked-by: Arnd Bergmann <arnd@xxxxxxxx> 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