[v3] random: use static branch for crng_ready()

Since crng_ready() is only false briefly during initialization and then
forever after becomes true, we don't need to evaluate it after, making
it a prime candidate for a static branch.

One complication, however, is that it changes state in a particular call
to credit_init_bits(), which might be made from atomic context, which
means we must kick off a workqueue to change the static key.

Further complicating things, credit_init_bits() may be called
sufficiently early on in system initialization such that system_wq is
NULL. In that case, we skip scheduling the work item from
credit_init_bits(), but check to see if the rng is already initialized
by the time it hits random_init(), in which case we assume that there
was no crediting event between system_wq becoming non-NULL and
random_init() being called, so we schedule the work then.

We make that assumption because this is still being called in an early
boot environement in which IRQs are disabled. To understand more
clearly, the two flows are as follows.

First possibility, in which credit_init_bits() is called relatively late
in boot:

  - workqueue_init_early()
  - ...
  - random_init()
    * crng_ready()==false → do nothing
  - ...
  - credit_init_bits(256)
    * system_wq!=NULL → schedule_work()

Second possibility, in which credit_init_bits() is called by the super
early EFI-handling code:

  - credit_init_bits(256)
    * system_wq==NULL → do nothing
  - workqueue_init_early()
  - rcu_init(), trace_init(), initcall_debug_enable(),
    context_tracking_init(), early_irq_init(), init_IRQ(), tick_init(),
    rcu_init_nohz(), init_timers(), srcu_init(), hrtimers_init(),
    softirq_init(), timekeeping_init(), kfence_init(), time_init()
    * We assume that none of these call credit_init_bits(). Since IRQs
      are still off, we don't have to worry about other code preempting
      these.
  - random_init()
    * crng_ready()==true → schedule_work()

Finally, schedule_work() must be called outside of the base_crng.lock,
because it can call into get_random_u32() itself, which will in some
cases attempt to acquire that same lock. So we hoist it outside of the
locked region, and ensure that the branches for that complexity get
removed as well.

Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Sultan Alsawaf <sultan@kerneltoast.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
Dominik - this is somewhat reminiscent of the misery we went through
with the NUMA node workqueue situation, which I was pretty happy about
removing. Hopefully recent other simplifications make adding something
similar back in not quite as bad, but if you've got the bandwidth, this
could use another pair of eyes. -Jason

Changes v2->v3:
- Call schedule_work() outside of the lock.

Changes v1->v2:
- Use a workqueue instead of doing it on-demand.

 drivers/char/random.c | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

Am Thu, May 12, 2022 at 06:37:48PM +0200 schrieb Jason A. Donenfeld:
> Since crng_ready() is only false briefly during initialization and then
> forever after becomes true, we don't need to evaluate it after, making
> it a prime candidate for a static branch.
> 
> One complication, however, is that it changes state in a particular call
> to credit_init_bits(), which might be made from atomic context, which
> means we must kick off a workqueue to change the static key. Further
> complicating things, credit_init_bits() may be called sufficiently early
> on in system initialization such that system_wq is NULL.
> 
> Fortunately, there exists the nice function execute_in_process_context(),
> which will immediately execute the function if !in_interrupt(), and
> otherwise defer it to a workqueue. During early init, before workqueues
> are available, in_interrupt() is always false, because interrupts
> haven't even been enabled yet, which means the function in that case
> executes immediately. Later on, after workqueues are available,
> in_interrupt() might be true, but in that case, the work is queued in
> system_wq and all goes well.

	Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>

Thanks,
	Dominik