Re: [PATCH] Make rcutorture RNG use temporal entropy

Satyam Sharma
2007-09-04T05:33:58Z

Hi Paul,

On Wed, 15 Aug 2007, Paul E. McKenney wrote:
>
> The locking used by get_random_bytes() can conflict with the
> preempt_disable() and synchronize_sched() form of RCU. This patch changes
> rcutorture's RNG to gather entropy from the new cpu_clock() interface
> (relying on interrupts, preemption, daemons, and rcutorture's reader
> thread's rock-bottom scheduling priority to provide useful entropy),
> and also adds and EXPORT_SYMBOL_GPL() to make that interface available
> to GPLed kernel modules such as rcutorture.

Honestly, rcutorture goes to some amazing lengths just to have this
randomizing-the-delays-that-read/write-test-threads-spend-inside-or-
outside-the-critical-sections thing :-) Especially, seeing that
synchro-test, the other "comparable" module, just doesn't bother with
all this at all. (especially check out its load == interval == do_sched
== 0 case! :-)

So IMHO, considering that rcutorture isn't a "serious" user of randomness
in the first place (of even a "fast-and-loose version" for that matter),
you could consider a solution where you gather all the randomness you need
at module_init time itself and save it somewhere, and then use it wherever
you're calling into rcu_random()->cpu_clock() [ or get_random_bytes() ]
in the current code. You could even make some trivial updates to those
random numbers after every RCU_RANDOM_REFRESH uses, like present.

Agreed, anybody running rcutorture isn't really looking for performance,
but why call get_random_bytes() or cpu_clock() (and the smp_processor_id()
+ irq_save/restore + export_symbol() that goes with it) when it isn't
_really_ "required" as such ...

Just a suggestion,

Satyam