Hi Jason,

quite late but finally the s390 vdso getrandom implementation which applies
on top of your random git tree.

As a prerequisite this requires some changes to s390 core code to allow
alternatives in vdso code. It is fine when all of this gets routed via your
tree.

Please note that the first patch of this series is already in linux-next
[1], but given that it is so small it seems to be the easiest to apply it
also on your tree; but I'm sure somebody will complain :)

Thanks,
Heiko

[1] 0147addc4fb7 ("s390/facility: Disable compile time optimization for decompressor code")

Heiko Carstens (7):
  s390/facility: Disable compile time optimization for decompressor code
  s390/alternatives: Remove ALT_FACILITY_EARLY
  s390/facility: Let test_facility() generate static branch if possible
  s390/module: Provide find_section() helper
  s390/vdso: Allow alternatives in vdso code
  s390/vdso: Move vdso symbol handling to separate header file
  s390/vdso: Wire up getrandom() vdso implementation

 arch/s390/Kconfig                           |   1 +
 arch/s390/include/asm/alternative.h         |   6 +-
 arch/s390/include/asm/facility.h            |  37 +++-
 arch/s390/include/asm/fpu-insn-asm.h        |  22 +++
 arch/s390/include/asm/module.h              |  14 ++
 arch/s390/include/asm/vdso-symbols.h        |  17 ++
 arch/s390/include/asm/vdso.h                |  12 --
 arch/s390/include/asm/vdso/getrandom.h      |  40 +++++
 arch/s390/include/asm/vdso/vsyscall.h       |  15 ++
 arch/s390/kernel/compat_signal.c            |   2 +-
 arch/s390/kernel/entry.S                    |   2 +-
 arch/s390/kernel/signal.c                   |   2 +-
 arch/s390/kernel/vdso.c                     |  26 ++-
 arch/s390/kernel/vdso64/Makefile            |   9 +-
 arch/s390/kernel/vdso64/vdso.h              |   1 +
 arch/s390/kernel/vdso64/vdso64.lds.S        |   7 +
 arch/s390/kernel/vdso64/vgetrandom-chacha.S | 184 ++++++++++++++++++++
 arch/s390/kernel/vdso64/vgetrandom.c        |  14 ++
 tools/arch/s390/vdso                        |   1 +
 tools/testing/selftests/vDSO/Makefile       |   2 +-
 20 files changed, 378 insertions(+), 36 deletions(-)
 create mode 100644 arch/s390/include/asm/vdso-symbols.h
 create mode 100644 arch/s390/include/asm/vdso/getrandom.h
 create mode 100644 arch/s390/kernel/vdso64/vgetrandom-chacha.S
 create mode 100644 arch/s390/kernel/vdso64/vgetrandom.c
 create mode 120000 tools/arch/s390/vdso

-- 
2.43.0

Hey Heiko,

On Fri, Sep 13, 2024 at 03:05:36PM +0200, Heiko Carstens wrote:
> Hi Jason,
> 
> quite late but finally the s390 vdso getrandom implementation which applies
> on top of your random git tree.
> 
> As a prerequisite this requires some changes to s390 core code to allow
> alternatives in vdso code. It is fine when all of this gets routed via your
> tree.

On first glance, this series looks perfect. I can't comment too much on
the s390 parts, but first pass of the crypto/vdso/api parts looks spot
on. Nice going.

Were you thinking you'd like me to take these via the random.git tree
for 6.12 next week, or were you thinking of delaying it a release and
taking it into the arch tree for 6.13?

Jason

On Fri, Sep 13, 2024 at 03:52:39PM +0200, Jason A. Donenfeld wrote:
> Hey Heiko,
> 
> On Fri, Sep 13, 2024 at 03:05:36PM +0200, Heiko Carstens wrote:
> > Hi Jason,
> > 
> > quite late but finally the s390 vdso getrandom implementation which applies
> > on top of your random git tree.
> > 
> > As a prerequisite this requires some changes to s390 core code to allow
> > alternatives in vdso code. It is fine when all of this gets routed via your
> > tree.
> 
> On first glance, this series looks perfect. I can't comment too much on
> the s390 parts, but first pass of the crypto/vdso/api parts looks spot
> on. Nice going.
> 
> Were you thinking you'd like me to take these via the random.git tree
> for 6.12 next week, or were you thinking of delaying it a release and
> taking it into the arch tree for 6.13?

If you did want it to be in 6.12, assuming this series continues to look
good, I think we'd still want it to be in -next for at least a week, so
maybe that'd take the form of me sending an additional late pull during
the merge window for this. Either way, I'll defer to your judgement
here, as most of these changes are fiddly s390 things more than anything
else.

Jason

Hi Jason,

> > On first glance, this series looks perfect. I can't comment too much on
> > the s390 parts, but first pass of the crypto/vdso/api parts looks spot
> > on. Nice going.
> > 
> > Were you thinking you'd like me to take these via the random.git tree
> > for 6.12 next week, or were you thinking of delaying it a release and
> > taking it into the arch tree for 6.13?
> 
> If you did want it to be in 6.12, assuming this series continues to look
> good, I think we'd still want it to be in -next for at least a week, so
> maybe that'd take the form of me sending an additional late pull during
> the merge window for this. Either way, I'll defer to your judgement
> here, as most of these changes are fiddly s390 things more than anything
> else.

This series is intended to go into 6.12. I don't see a reason to delay
this for a full release cycle. If something breaks we'll fix it, as usual.

So a late pull request would be perfectly fine. Alternatively we can
take this via s390 also for a second pull request; whatever you prefer
and is less work for you.

On Fri, Sep 13, 2024 at 04:29:24PM +0200, Heiko Carstens wrote:
> Hi Jason,
> 
> > > On first glance, this series looks perfect. I can't comment too much on
> > > the s390 parts, but first pass of the crypto/vdso/api parts looks spot
> > > on. Nice going.
> > > 
> > > Were you thinking you'd like me to take these via the random.git tree
> > > for 6.12 next week, or were you thinking of delaying it a release and
> > > taking it into the arch tree for 6.13?
> > 
> > If you did want it to be in 6.12, assuming this series continues to look
> > good, I think we'd still want it to be in -next for at least a week, so
> > maybe that'd take the form of me sending an additional late pull during
> > the merge window for this. Either way, I'll defer to your judgement
> > here, as most of these changes are fiddly s390 things more than anything
> > else.
> 
> This series is intended to go into 6.12. I don't see a reason to delay
> this for a full release cycle. If something breaks we'll fix it, as usual.
> 
> So a late pull request would be perfectly fine. Alternatively we can
> take this via s390 also for a second pull request; whatever you prefer
> and is less work for you.

Okay, great. I'll queue it up then in random.git.

Jason