[PATCH] random: don't try to look at entropy_count outside the lock

[Matt Mackall <mpm@selenic.com>]

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>

diff -r 4d01a524fee5 drivers/char/random.c
--- a/drivers/char/random.c	Wed Sep 03 07:30:13 2008 -0700
+++ b/drivers/char/random.c	Wed Sep 17 17:20:14 2008 -0700
@@ -407,7 +407,7 @@
 	/* read-write data: */
 	spinlock_t lock;
 	unsigned add_ptr;
-	int entropy_count;	/* Must at no time exceed ->POOLBITS! */
+	int entropy_count;
 	int input_rotate;
 };
 
@@ -727,11 +727,10 @@
 {
 	unsigned long flags;
 
-	BUG_ON(r->entropy_count > r->poolinfo->POOLBITS);
-
 	/* Hold lock while accounting */
 	spin_lock_irqsave(&r->lock, flags);
 
+	BUG_ON(r->entropy_count > r->poolinfo->POOLBITS);
 	DEBUG_ENT("trying to extract %d bits from %s\n",
 		  nbytes * 8, r->name);
 

-- 
Mathematics is the supreme nostalgia of our time.