David Sterba wrote on 2016/05/24 11:51 +0200:
On Tue, May 24, 2016 at 08:31:01AM +0800, Qu Wenruo wrote:
This could be made static (with thread local storage) so the state does
not get regenerated all the time. Possibly it could be initialize from
some true random source, not time or pid.
I also considered true random source like /dev/random, but since it's
possible to wait for entropy pool, it would be quite slow and confusing
for users.
How would it be confusing? We'll once seed the random generator from
/dev/random, reading 3 * 16bit for the nrand generator context.
Reading from /dev/random may sleep, until the entropy pool is filled.
This may cause any caller of the new random API sleep for a long time.
Just like when using openssl to generate private key.
Also, for current use case, I didn't think we really need that true
random bytes even as random seed.
We're not generating key pair, we only need to make the numbers seems to
be random(pseudo random).
So IMHO the cost of hanging btrfs-corrupt-block is not validated for
just true random seed.
Thanks,
Qu
So time with pid seems good enough.
Only as a fallback if /dev/random is not available at all.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
