Re: [PATCH 06/10] random: use the arch-specific rng in xfer_secondary_pool

[Linus Torvalds]

On Thu, Jul 5, 2012 at 11:12 AM, Theodore Ts'o <tytso@xxxxxxx> wrote:
> If the CPU supports a hardware random number generator, use it in
> xfer_secondary_pool(), where it will significantly improve things and
> where we can afford it.

Ok, this makes the other patch look much better, in that hopefully
"get_random_bytes()" at least is guaranteed to use the hw randomness.

HOWEVER, it does look a bit bogus. Why use "arch_get_random_int()",
when "arch_get_random_long()" gives you potentially twice the amount
at the same cost? Also, you already have a 128-byte array on the stack
(tmp[]), please don't make the stack cost of this thing even bigger.
Use a "union" to hold both tmp[] and hwrand[] without growing the
stack unnecessarily.

Also, you should not use "cycle_t cycles" - your changes to the struct
are not an improvement. The high bits of "cycles" have no actual
randomness in them, and you're just making things more expensive for
no reason.  At least on x86, the low 32 bits of the cycles are cheaper
than the whole 64-bit value. So using more bits guys you nothing, and
only makes the code slower.

                    Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/