Re: [PATCH v1 1/1] s390/arch_random: Buffer true random data

["Jason A. Donenfeld" <Jason@zx2c4.com>]

Hi Christian,

On Wed, Jul 06, 2022 at 08:29:49PM +0200, Christian Borntraeger wrote:
> >> However, with so few invocations it should not make any harm when there
> >> is a
> >> even very expensive trng() invocation in interrupt context.
> >>
> >> But I think we should check, if this is really something to backport to
> >> the older
> >> kernels where arch_get_random_seed_long() is called really frequency.
> > 
> > I backported the current random.c design to old kernels, so the
> > situation there should be the same as in 5.19-rc5.
> > 
> > So if you feel such rare usage is find even in_hardirq(), then I suppose
> > there's nothing more to do here?
> 
> I think up to 190µs in interrupt can result in unwanted latencies. Yes it does not
> happen that often and it is smaller than most timeslices of hypervisors.
> So I would likely turn that question around
> what happens if we return false if in_hardirq is true? Any noticeable
> delays in code that uses random numbers?

I think I already answered this here with mention of the hwrng driver:
https://lore.kernel.org/all/YsSAn2qXqlFkS5sH@zx2c4.com/

Anyway, I would recommend keeping it available in all contexts, so that
s390 isn't a special case to keep in mind, and because Harald said he
couldn't measure an actual problem existing for real. Plus, it's not as
though we're talking about RT kernels or a problem that would affect RT.
But if you're convinced that even the extremely rare case poses a issue,
doing the !in_hardirq() thing won't be the end of the world either and
is partly mitigated by the hwrng driver mentioned earlier. So I think
it's mostly up to you guys on what the tradeoffs are and what's
realistic and such.

Jason