Re: [PATCH-RFC] Improve randomness of hash_long on 64bit.

[Neil Brown <neilb@suse.de>]

On Thursday May 11, akpm@osdl.org wrote:
> 
> We end up with
> 
> static inline u32 hash_u32(u32 val, unsigned int bits)
> {
> 	u32 hash = val;
> 
> 	/* On some cpus multiply is faster, on others gcc will do shifts */
> 	hash *= GOLDEN_RATIO_PRIME_32;
> 
> 	/* High bits are more random, so use them. */
> 	return hash >> (32 - bits);
> }
> 
> static inline u32 hash_u64(u64 val, unsigned int bits)
> {
> 	u32 hi = val >> 32;
> 	return hash_u32(hash_u32(val, 32) ^ hi, bits);
> }
> 
> So if one does
> 
> 	hash_u64(foo, 44)
> 
> we have a negative shift distance.

True.  But as hash_u64 returns a u32, asking for 44 bits would be
clearly unwise.  It really no different than doing

        hash_long(foo, 100)

Based on the return type, that is equally unwise.

Fortunately no one (current) askes for more than 14 bits.

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