On Mon, May 2, 2016 at 3:20 AM, George Spelvin <linux@xxxxxxxxxxx> wrote:
>
> After a careful scan through the kernel code, no caller asks any of
> those four for more than 32 bits of hash result, except that the
> latter two need 64 bits from hash_long() if BITS_PER_LONG == 64.
Ugh. I hate this patch.
I really think that we should *not* convuse those two odd svcauth.h
users with the whole hash_32/64 thing.
I think hash_str/hash_mem should be moved to lib/hash.c, and they
just shouldn't use "hash_long()" at all, except at the verty end (they
currently have a very odd way of doing "every <n> bytes _and_ at the
end".
In particular, the hashing in the *middle* is very different from the
hashing at the end.
At the end, you need to make sure the lower bits get spread out
particularly to the upper bits, since you're going to shift things
down.
But in the middle, you just want to spread the bits out (and in
particular, destroy any byte-per-byte patterns that it build it in
between).
Quite frankly, I think those functions should just use something like
the FNV hash (or Jenkins hash), and then maybe use "hash_long()" at
the *end* to shift the result down to "bits".
I don't want to make our <linux/hash.h> odder just because of two
entirely broken users.
That said, I actually think hash_str() should be killed entirely.
Better just use what we use for pathnames: full_name_hash() (which
gets a pointer and length) and hash_name (which gets the string).
Those functions do the "word-at-a-time" optimization, and they should
do a good enough job. If they aren't, we should fix them, because they
are a hell of a lot more important than anything that the svcauth code
does.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
