For architectures that don't have cycle counters, the algorithm for
deciding when to avoid giving entropy credit due to back-to-back timer
interrupts didn't make any sense, since we were checking every 64
interrupts. Change it so that we only give an entropy credit if the
majority of the interrupts are not based on the timer.
Signed-off-by: Theodore Ts'o <ty...@mit.edu>
Cc: George Spelvin <li...@horizon.com>
---
drivers/char/random.c | 26 ++++++++++++--------------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 9a59101..60eecfc 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -548,9 +548,9 @@ static void mix_pool_bytes(struct entropy_store *r, const
void *in,
struct fast_pool {
__u32 pool[4];
unsigned long last;
- unsigned short count;
+ unsigned char count;
+ unsigned char notimer_count;
unsigned char rotate;
- unsigned char last_timer_intr;
};
/*
@@ -850,6 +850,8 @@ void add_interrupt_randomness(int irq, int irq_flags)
input[3] = ip >> 32;
fast_mix(fast_pool, input);
+ if ((irq_flags & __IRQF_TIMER) == 0)
+ fast_pool->notimer_count++;
if ((fast_pool->count & 63) && !time_after(now, fast_pool->last + HZ))
return;
@@ -874,19 +876,15 @@ void add_interrupt_randomness(int irq, int irq_flags)
spin_unlock(&r->lock);
/*
- * If we don't have a valid cycle counter, and we see
- * back-to-back timer interrupts, then skip giving credit for
- * any entropy, otherwise credit 1 bit.
+ * If we have a valid cycle counter or if the majority of
+ * interrupts collected were non-timer interrupts, then give
+ * an entropy credit of 1 bit. Yes, this is being very
+ * conservative.
*/
- credit++;
- if (cycles == 0) {
- if (irq_flags & __IRQF_TIMER) {
- if (fast_pool->last_timer_intr)
- credit--;
- fast_pool->last_timer_intr = 1;
- } else
- fast_pool->last_timer_intr = 0;
- }
+ if (cycles || (fast_pool->notimer_count >= 32))
+ credit++;
+
+ fast_pool->count = fast_pool->notimer_count = 0;
credit_entropy_bits(r, credit);
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
