Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> > Implement a function to generate hashes. It needs to be stable over time
> > and endianness-independent as the hashes will appear on disk in future
> > patches.
>
> I'm not actually seeing this being endianness-independent.
>
> Is the input just regular 32-bit data in native word order? Because
> then it's not endianness-independent, it's purely that there *is* no
> endianness to the data at all and it is purely native data.
>
> So the code may be correct, but the explanation is confusing. There is
> absolutely nothing here that is about endianness.
What I'm trying to get at is that the hash needs to be consistent, no matter
the endianness of the cpu, for any particular input blob. The hashing
function shouldn't need to know the structure of the input blob. In the case
of the volume key, it's a padded printable string; in the case of the cookie
key, it's probably some sort of structured blob, quite possibly an actual
array of be32.
The reason it needs to be consistent is that people seem to like seeding the
cache by tarring up the cache from one machine and untarring it on another.
And looking again at my code:
unsigned int fscache_hash(unsigned int salt, unsigned int *data, unsigned int n)
{
unsigned int a, x = 0, y = salt;
for (; n; n--) {
a = *data++; <<<<<<<
HASH_MIX(x, y, a);
}
return fold_hash(x, y);
}
The marked line should probably use something like le/be32_to_cpu().
I also need to fix 9p to canonicalise its cookie key.
Thanks for catching that,
David
