On Sat, Apr 23 2022 at 23:26, Jason A. Donenfeld wrote: > The addition of random_get_entropy_fallback() provides access to > whichever time source has the highest frequency, which is useful for > gathering entropy on platforms without available cycle counters. It's > not necessarily as good as being able to quickly access a cycle counter > that the CPU has, but it's still something, even when it falls back to > being jiffies-based. > > In the event that a given arch does not define get_cycles(), falling > back to the get_cycles() default implementation that returns 0 is really > not the best we can do. Instead, at least calling > random_get_entropy_fallback() would be preferable, because that always > needs to return _something_, even falling back to jiffies eventually. > It's not as though random_get_entropy_fallback() is super high precision > or guaranteed to be entropic, but basically anything that's not zero all > the time is better than returning zero all the time. > > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Cc: Arnd Bergmann <arnd@xxxxxxxx> > Cc: Theodore Ts'o <tytso@xxxxxxx> > Signed-off-by: Jason A. Donenfeld <Jason@xxxxxxxxx> Not that I care much, but in general taking over authorship w/o attribution via Suggested-by or such is frowned upon. Thanks, tglx