Hi Sven, On Thu, Sep 15, 2022 at 1:22 AM Sven van Ashbrook <svenva@xxxxxxxxxxxx> wrote: > - if (!kthread_should_stop() && crng_ready()) > - schedule_timeout_interruptible(CRNG_RESEED_INTERVAL); > + return crng_ready() ? CRNG_RESEED_INTERVAL : 0; 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. The other thing that occurred to me when reading this patch in context of the other one is that this sleep you're removing here is not the only sleep in the call chain. Each hwrng driver can also sleep, and many do, sometimes for a long time, blocking until there's data available, which might happen after minutes in some cases. So maybe that's something to think about in context of this patchset -- that just moving this to a delayed worker might not actually fix the issue you're having with sleeps. Jason
