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@xxxxxxxxx/ 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
