summaryrefslogtreecommitdiffstats
path: root/CREDITS
diff options
context:
space:
mode:
authorMatt Mackall <mpm@selenic.com>2009-01-06 14:42:55 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2009-01-06 15:59:30 -0800
commitcda796a3d572059d64f5429dfc1d00ca6fcbaf8d (patch)
tree622c2b4d01d99e6c26a4f0ea554f866151becb2f /CREDITS
parent71183c94804e8e19be32acccc8a019ffb445ec2b (diff)
downloadkernel-crypto-cda796a3d572059d64f5429dfc1d00ca6fcbaf8d.tar.gz
kernel-crypto-cda796a3d572059d64f5429dfc1d00ca6fcbaf8d.tar.xz
kernel-crypto-cda796a3d572059d64f5429dfc1d00ca6fcbaf8d.zip
random: don't try to look at entropy_count outside the lock
As a non-atomic value, it's only safe to look at entropy_count when the pool lock is held, so we move the BUG_ON inside the lock for correctness. Also remove the spurious comment. It's ok for entropy_count to temporarily exceed POOLBITS so long as it's left in a consistent state when the lock is released. This is a more correct, simple, and idiomatic fix for the bug in 8b76f46a2db. I've left the reorderings introduced by that patch in place as they're harmless, even though they don't properly deal with potential atomicity issues. Signed-off-by: Matt Mackall <mpm@selenic.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'CREDITS')
0 files changed, 0 insertions, 0 deletions