Rene Herman wrote on 18.08.2008 23:23:
On 18-08-08 19:25, Stanichenko Marat wrote:
From: Stanichenko Marat <mstanichenko@xxxxxxxxx>
Add the interface that shows the amount of entropy generated via the
interfaces and also the amount consumed. This patch adds two files in
proc. The first of them shows the entropy generated per interface, the
second one - the amount consumed from blocking (/dev/random) and
nonblocking (/dev/urandom) pools.
This patch is an attempt to realize "/dev/random statistics" project
of kernel newbies community.
http://kernelnewbies.org/KernelProjects
Signed-off-by: Stanichenko Marat <mstanichenko@xxxxxxxxx>
Just two quick comments/questions as encountered while reading. I'm not
familiar with the random code or anything.
First, your patch was posted Base64 encoded which doesn't make it easier
to look at/comment on. Base64 encoding even text/plain attchments is a
longstanding Thunderbird bug when your outgoing charset is set to UTF-8
(and the reason why my outgoing charset is ISO8859-15; you just won't
remember to switch from UTF-8 to something else every time when posting
a patch otherwise).
Thank you very much for respond. Yes, I'm sorry, I'll fix this issue and
set outgoing charset to ISO8859-15 if I send a patch another time.
+struct ioctl_rand_stat {
+ unsigned nbits;
+ spinlock_t lock;
+};
+static struct ioctl_rand_stat ent_ioctl_produce = {
+ .nbits = 0,
+ .lock = __SPIN_LOCK_UNLOCKED(&input_timer_state.lock),
Is that supposed to be &ent_ioctl_produce.lock?
Yes, of course, my bad.
@@ -621,8 +645,11 @@ static void add_timer_randomness(struct
* Round down by 1 bit on general principles,
* and limit entropy entimate to 12 bits.
*/
- credit_entropy_bits(&input_pool,
- min_t(int, fls(delta>>1), 11));
+ nbits = min_t(int, fls(delta>>1), 11);
+ spin_lock_irqsave(&state->lock, flags);
+ state->nbits += nbits;
+ spin_unlock_irqrestore(&state->lock, flags);
+ credit_entropy_bits(&input_pool,nbits);
Couldn't state->nbits be an atomic_t? The locking looks like it might be
a little expensive. Maybe they should be per-cpu? I have no idea about
the frequencies here...
I've thought about this:
about atomic_t:
- atomic_t might be 2^24 as a maximum value (on SPARC arch). I've
created VMWare test machine and left it without any special load for a
day. Then I measured the value of produced entropy. The max number was
about 30000. 2^24/30000 ~ 559 days without overflowing. I don't know if
it suits for our purpose... that's why I rejected this approach.
about per-cpu variables:
- the function called with interrupts enable so if I use spinlock I must
disable interrupts, am I right?
Rene.
Stanichenko Marat
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
