getrandom() vDSO archs (arm64, ppc, loongarch) for 6.12 [Was: Re: [PATCH v2 00/17] Wire up getrandom() vDSO implementation on powerpc]

[Jason A. Donenfeld]

Hey again,

On Mon, Aug 26, 2024 at 09:19:22AM +0200, Jason A. Donenfeld wrote:
> Thanks for this series. There are quite a few preliminary patches in it,
> before you get to the PPC part, which fix up general build system or test
> harness correctness issues. Since some of those affect all architectures
> that are adding vDSO getrandom() support for 6.12, I'm going to take
> those into my random.git tree as a fix for 6.11 now, in hopes that the
> new archs can mostly go into arch trees without too many tree
> interdependencies.
> 
> So I'll reply to individual patches for that, mentioning which ones I
> extract.

Seeing the volume of these and the amount of ground they touch, I'm now
having second thoughts about rushing this into 6.11. Particularly with
the header changes, I think it might be smart to let it cook in
linux-next for a bit before sending it to Linus.

  $ git --no-pager diff --name-only linus/master
  arch/x86/entry/vdso/vma.c
  arch/x86/include/asm/pvclock.h
  arch/x86/include/asm/vdso/vsyscall.h
  drivers/char/random.c
  include/asm-generic/unaligned.h
  include/vdso/helpers.h
  include/vdso/unaligned.h
  lib/vdso/Makefile
  lib/vdso/getrandom.c
  tools/arch/x86/vdso
  tools/include/linux/linkage.h
  tools/testing/selftests/vDSO/Makefile
  tools/testing/selftests/vDSO/vdso_config.h
  tools/testing/selftests/vDSO/vdso_test_getrandom.c

So I think what I'll do is, for 6.11-rc6, send in the real bug fixes,
which right now amount to:

  - random: vDSO: reject unknown getrandom() flags
  - random: vDSO: don't use 64-bit atomics on 32-bit architectures

  $ git --no-pager diff --name-only linus/master..a90592ab7cad
  drivers/char/random.c
  lib/vdso/getrandom.c

And then for the pending aarm64, ppc64(/32?), and loongarch enablement
patches for 6.12, I'll just take those through my random.git tree, which
have all of these build-system preliminaries. And then we'll obviously
require acks from the maintainers of the archs for each of those arch
enablement patches.

If that sounds like an acceptable plan, you might want to mention in the
cover letter that you're basing your arch-specific patches on
https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/ and
want an ack from the arch maintainer, etc.

Jason