2022-03-20 3:34 GMT+09:00, Steve French <smfrench@xxxxxxxxx>:
> 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 don't understand why only FileId fields should be declared as u64 not le64.
It means that FileID doesn't need byteswap in client? samba seems to
stores them in little-endian byte order.
#define SBVAL(p, ofs, v) PUSH_LE_U64(p, ofs, v)
SBVAL(outbody.data, 0x40,
out_file_id_persistent); /* file id (persistent) */
SBVAL(outbody.data, 0x48,
out_file_id_volatile); /* file id (volatile) */
Am I missing something ?
>
>
> 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
>
