On 3/20/2022 10:13 PM, ronnie sahlberg wrote:
On Sun, Mar 20, 2022 at 7:24 PM Steve French <smfrench@xxxxxxxxx> wrote:
They probably should be always 'u64' everywhere (not le64) and change
the code back in fs/smbfs_common/smb2pdu.h (was this due to ksmbd
using the file and converting these fields in fs/smbfs_common) rather
than the ones you changed
I agree, they should not be le64 as that implies there is a byteorder
for this field, so u64 seems better.
(Technically, it should probably not even be an integer and instead be
unsigned char[8]
but that seems like overkill.)
So that was my original suggestion. The FID is not an integer at all.
I don't think it's overkill personally.
Tom.
On Sat, Mar 19, 2022 at 11:01 AM Paulo Alcantara <pc@xxxxxx> wrote:
Yes, I agreed. Why not simply store them as le64 and avoid the byteswapping altogether?
On 19 March 2022 09:06:55 GMT-03:00, Tom Talpey <tom@xxxxxxxxxx> wrote:
On 3/19/2022 12:23 AM, Steve French wrote:
Any comments on Paulo's patch? It fixes an endian conversion problem
that can affect file ids used on big endian archs. I will add cc:
stable
https://git.cjr.nz/linux.git/commit/?h=cifs-bad-fid-fixes&id=a857bb6b15646a7946fafb281878ddf498107dc3
It seems a bad idea to be storing opaque fields in le64 integers, then
byteswapping them when they go back on the wire. Wouldn't it be better
to make them u8[8] arrays and just use memcpy/memcmp?
Tom.
--
Thanks,
Steve
