From cda796a3d572059d64f5429dfc1d00ca6fcbaf8d Mon Sep 17 00:00:00 2001 From: Matt Mackall Date: Tue, 6 Jan 2009 14:42:55 -0800 Subject: [PATCH] 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 Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- drivers/char/random.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index c7afc068c28..7c13581ca9c 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -407,7 +407,7 @@ struct entropy_store { /* read-write data: */ spinlock_t lock; unsigned add_ptr; - int entropy_count; /* Must at no time exceed ->POOLBITS! */ + int entropy_count; int input_rotate; }; @@ -767,11 +767,10 @@ static size_t account(struct entropy_store *r, size_t nbytes, int min, { 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);