Re: [PATCH v2] hw_random: use add_hwgenerator_randomness() for early entropy

[Dominik Brodowski <linux@dominikbrodowski.net>]

Am Sun, Nov 06, 2022 at 02:50:42AM +0100 schrieb Jason A. Donenfeld:
> Rather than calling add_device_randomness(), the add_early_randomness()
> function should use add_hwgenerator_randomness(), so that the early
> entropy can be potentially credited, which allows for the RNG to
> initialize earlier without having to wait for the kthread to come up.

We're already at device_initcall() level here, so that shouldn't be much of
an additional delay.

> Since we don't want to sleep from add_early_randomness(), we also
> refactor the API a bit so that hw_random/core.c can do the sleep, this
> time using the correct function, hwrng_msleep, rather than having
> random.c awkwardly do it.

Isn't this something you were quite hesistant about just recently[*]?

| I was thinking the other day that under certain circumstances, it
| would be nice if random.c could ask hwrng for more bytes NOW, rather
| than waiting. With the code as it is currently, this could be
| accomplished by having a completion event or something similar to
| that. With your proposed change, now it's left up to the hwrng
| interface to handle.
| 
| That's not the end of the world, but it does mean we'd have to come up
| with a patch down the line that exports a hwrng function saying, "stop
| the delays and schedule the worker NOW". Now impossible, just more
| complex, as now the state flow is split across two places. Wondering
| if you have any thoughts about this.

Thanks,
	Dominik

[*] https://lore.kernel.org/lkml/CAHmME9rhunb05DEnc=UfGr8k9_LBi1NW2Hi0OsRbGwcCN2NzjQ@mail.gmail.com/