[PATCH v2 10/67] fscache: Implement cookie registration
Linus Torvalds
torvalds at linux-foundation.org
Thu Dec 9 09:21:57 PST 2021
On Thu, Dec 9, 2021 at 8:55 AM David Howells <dhowells at redhat.com> wrote:
>
> + buf = (u32 *)cookie->inline_key;
> + }
> +
> + memcpy(buf, index_key, index_key_len);
> + cookie->key_hash = fscache_hash(cookie->volume->key_hash, buf, bufs);
This is actively wrong given the noise about "endianness independence"
of the fscache_hash() function.
There is absolutely nothing endianness-independent in the above.
You're taking some random data, casting the pointer to a native
word-order 32-bit entity, and then doing things in that native word
order.
The same data will give different results on different endiannesses.
Maybe some other code has always munged stuff so that it's in some
"native word format", but if so, the type system should have been made
to match. And it's not. It explicitly casts what is clearly some other
pointer type to "u32 *".
There is no way in hell this is properly endianness-independent with
each word in an array having some actual endianness-independent value
when you write code like this.
I'd suggest making endianness either explicit (make things explicitly
"__le32" or whatever) and making sure that you don't just randomly
cast pointers, you actually have the proper types.
Or, alternatively, just say "nobody cares about BE any more,
endianness isn't relevant, get over it".
But don't have functions that claim to be endianness-independent and
then randomly access data like this.
Linus
More information about the linux-afs
mailing list