svn commit: r253786 - in head/sys: dev/random modules/padlock_rng modules/rdrand_rng modules/yarrow_rng

[Andrey Chernov]

On 31.07.2013 4:15, David O'Brien wrote:
> On Tue, Jul 30, 2013 at 05:07:46PM -0700, David O'Brien (@FreeBSD) wrote:
>> I believe you're talking about this code in
>> sys/libkern/arc4random.c:arc4rand()
>>
>> 	if (atomic_cmpset_int(&arc4rand_iniseed_state, ARC4_ENTR_HAVE,
>> 	    ARC4_ENTR_SEED) || reseed ||
>> 	   (arc4_numruns > ARC4_RESEED_BYTES) ||
>> 	   (tv.tv_sec > arc4_t_reseed))
>> 		arc4_randomstir();
> 
> Looking at this, seems to me that it would be more optimized if we tested
> the things that are most likely to be TRUE first instead of those things
> most likely to be FALSE?  ARC4_ENTR_HAVE->ARC4_ENTR_SEED can only happen
> once per boot, and the 'reseed' flag is '0' in the majority of the
> arc4rand() callers.
> 

This code can be called concurrently, so the first part is to reseed
immediately if we have good entropy, making other threads wait for the
lock released in arc4_randomstir() and arc4_t_reseed, arc4_numruns
reset, so they don't call arc4_randomstir() in chain, if possible (small
window still exists, as it was in original code). While there is no harm
for arc4 algo itself to call arc4_randomstir() several times in line, it
is just CPU waste.

I don't touch the order of the rest conditions.

-- 
http://ache.vniz.net/
bitcoin:1G6ugdNY6e5jx1GVnAU2ntj2NEfmjKG85r