Re: Where exactly will arch_fast_hash be used

On So, 2014-12-07 at 14:41 +0100, Hannes Frederic Sowa wrote:

On So, 2014-12-07 at 08:30 -0500, George Spelvin wrote:

quoted

Thanks for the encouragement!

quoted

Please consider xfs, too.
AFAIK xfs doesn't seed their hashing so far and the hashing function is
pretty weak. One example:
http://marc.info/?l=linux-xfs&m=139590613002926&w=2

Is that something that *can* be changed without breaking the
disk format?  SipHash is explicitly *not* designed to be secure as
an unkeyed hash in the way that SHA-type algorithms are.

I did some research and it looked like it would need a change to the
disk format but it should be doable by incrementing the super block
version, so at least newly created filesystem would benefit from it.

quoted

What it's designed to do is provide second preimage resistance
of its output, or a function (like modular reduction) of its output,
against an attacker who doesn't know the secret seed.

quoted

Ack. If we want to use it in the networking stack we should be able to
use it without a dependency to the crypto framework.

Already understood.  My big question is whether a single function call
is okay or we need something inlinable.

Like md5_transfrom, I think a non-inline function would be just fine.
Otherwise kernel code size would increase. Most hash users in the
network stack mostly deal with less bytes of input than one round needs.

Of course, if it looks feasable (from a performance PoV, but I doubt
that) to migrate the current jhash users to siphash, it might be worth
dealing with larger input sizes and maybe also doing it inline. But that
very much depends on the code size it would add. Currently we use jhash
as the non-linear "secure" hashing functions at most places.

Also rhashtable takes a pointer to the hasing function, thus causing gcc
to generate a function in each compilation unit if it would be static
inline.