diff options
author | Jason A. Donenfeld <Jason@zx2c4.com> | 2022-03-08 20:12:16 +0300 |
---|---|---|
committer | Jason A. Donenfeld <Jason@zx2c4.com> | 2022-03-13 06:51:39 +0300 |
commit | 3e504d2026eb6c8762cd6040ae57db166516824a (patch) | |
tree | 7cd0e241000615b841b9be8837032dd1f45bac6c /kernel | |
parent | 7a7ff644aeaf071d433caffb3b8ea57354b55bd3 (diff) | |
download | linux-3e504d2026eb6c8762cd6040ae57db166516824a.tar.xz |
random: check for signal and try earlier when generating entropy
Rather than waiting a full second in an interruptable waiter before
trying to generate entropy, try to generate entropy first and wait
second. While waiting one second might give an extra second for getting
entropy from elsewhere, we're already pretty late in the init process
here, and whatever else is generating entropy will still continue to
contribute. This has implications on signal handling: we call
try_to_generate_entropy() from wait_for_random_bytes(), and
wait_for_random_bytes() always uses wait_event_interruptible_timeout()
when waiting, since it's called by userspace code in restartable
contexts, where signals can pend. Since try_to_generate_entropy() now
runs first, if a signal is pending, it's necessary for
try_to_generate_entropy() to check for signals, since it won't hit the
wait until after try_to_generate_entropy() has returned. And even before
this change, when entering a busy loop in try_to_generate_entropy(), we
should have been checking to see if any signals are pending, so that a
process doesn't get stuck in that loop longer than expected.
Cc: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Diffstat (limited to 'kernel')
0 files changed, 0 insertions, 0 deletions