linux-kernel - Re: [GIT PULL] Please pull NFS client changes for Linux 5.18

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHk-=wiOp=KpFAN_+dRVTuNdBVYUZ4nXP6sEYhDvTKdeJFEYUA@mail.gmail.com>
Date:   Wed, 30 Mar 2022 17:52:05 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Trond Myklebust <trondmy@...merspace.com>
Cc:     "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Please pull NFS client changes for Linux 5.18

On Wed, Mar 30, 2022 at 4:18 PM Trond Myklebust <trondmy@...merspace.com> wrote:
>
> Hmm... No there doesn't appear to be a huge difference between the two.

Ok, thanks for checking. It's basically what I would have expected,
both models really just depend on a reasonable mixing and shuffling of
bits in the word, and it really looks like they have very similar
collision behavior.

At some point even with equivalent functions you obviously end up with
just random differences that just depend on the input set and prue
luck.

But at least based on your numbers, it does look like they really are
equivalent, and hash_64() certainly doesn't look any worse.

All the extra work xxhash() does should matter mainly for

 (a) using more final bits of the hash (ir not reducing them in the end)

 (b) all the cases where you have much more input than one single word

Here, (b) obviously isn't an issue.

And that (a) is by design - those default kernel hash() functions are
literally designed for generating the index for hash tables, and so
expects that final reduction in size.

As a result, unlike xxhash(), it doesn't try to mix in bits in the low
bits, because it knows those will be shifted away in the use-case it's
designed for (the hash() reduction in bits always takes the high
bits).

But that use-case is really exactly what nfs is looking for too, which
is why I was expecting the regular hash_64() to JustWork(tm) for the
nfs case.

                 Linus