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.) > > > 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
