]> git.baikalelectronics.ru Git - kernel.git/commit
Merge branch 'entropy'
authorLinus Torvalds <torvalds@linux-foundation.org>
Mon, 30 Sep 2019 02:25:39 +0000 (19:25 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Mon, 30 Sep 2019 02:25:39 +0000 (19:25 -0700)
commit87881c27166d724d91a202e5b79bf9553b095458
tree075660db24621f4be8e24882bcaa88e15bc797f4
parentd9cdf2c185cf094365ce2fa3a0a4d82e3898f2d2
parenta545acb9dfc3a7abf4c9297a3a88e4f2d2ef9a09
Merge branch 'entropy'

Merge active entropy generation updates.

This is admittedly partly "for discussion".  We need to have a way
forward for the boot time deadlocks where user space ends up waiting for
more entropy, but no entropy is forthcoming because the system is
entirely idle just waiting for something to happen.

While this was triggered by what is arguably a user space bug with
GDM/gnome-session asking for secure randomness during early boot, when
they didn't even need any such truly secure thing, the issue ends up
being that our "getrandom()" interface is prone to that kind of
confusion, because people don't think very hard about whether they want
to block for sufficient amounts of entropy.

The approach here-in is to decide to not just passively wait for entropy
to happen, but to start actively collecting it if it is missing.  This
is not necessarily always possible, but if the architecture has a CPU
cycle counter, there is a fair amount of noise in the exact timings of
reasonably complex loads.

We may end up tweaking the load and the entropy estimates, but this
should be at least a reasonable starting point.

As part of this, we also revert the revert of the ext4 IO pattern
improvement that ended up triggering the reported lack of external
entropy.

* getrandom() active entropy waiting:
  Revert "Revert "ext4: make __ext4_get_inode_loc plug""
  random: try to actively add entropy rather than passively wait for it
drivers/char/random.c
fs/ext4/inode.c