Hi Arnd, On Mon, Nov 28, 2022 at 08:18:12PM +0100, Arnd Bergmann wrote: > On Mon, Nov 28, 2022, at 12:18, Jason A. Donenfeld wrote: > > Hook up the generic vDSO implementation to the x86 vDSO data page. Since > > the existing vDSO infrastructure is heavily based on the timekeeping > > functionality, which works over arrays of bases, a new macro is > > introduced for vvars that are not arrays. > > > > Also enable the vgetrandom_alloc() syscall, which the vDSO > > implementation relies on. > > > > The vDSO function requires a ChaCha20 implementation that does not write > > to the stack, yet can still do an entire ChaCha20 permutation, so > > provide this using SSE2, since this is userland code that must work on > > all x86-64 processors. > > > > Reviewed-by: Samuel Neves <sneves@xxxxxxxxx> # for vgetrandom-chacha.S > > Signed-off-by: Jason A. Donenfeld <Jason@xxxxxxxxx> > > --- > > arch/x86/Kconfig | 1 + > > arch/x86/entry/syscalls/syscall_64.tbl | 1 + > > I see that this enables the syscall in x86-64, while patch 1 > adds it to the eight architecures that use > include/uapi/asm-generic/unistd.h (with the __ARCH_WANT_* > guard at the moment, but you already said that will be removed) > > I think ideally the syscall.tbl and unistd.h changes should be done > in one patch for all architectures that doesn't mix it with > any other changes. In particular I think it should be separate > from the vdso changes, but could be in the patch that implements > the syscall. That's more or less how v7 was, but Thomas thought the x86 stuff should be separate. So for v8, the organization is: 1) generic syscall 2) generic vdso 3) x86 wiring The primary advantage is that future archs wanting to add this now can just look at commit (3) only, and make a similar commit for that new arch. If you think a different organization outweighs that advantage, can you spell out what division of patches you want, and I'll do that for v9? Or maybe this v8 is okay? Jason
