From: Steve French <smfrench@gmail.com>
To: Paulo Alcantara <pc@cjr.nz>, Namjae Jeon <linkinjeon@kernel.org>
Cc: Tom Talpey <tom@talpey.com>, CIFS <linux-cifs@vger.kernel.org>
Subject: Re: [PATCH] cifs: fix bad fids sent over wire
Date: Sat, 19 Mar 2022 13:34:47 -0500 [thread overview]
Message-ID: <CAH2r5mv2E=zQ+nVjMuLGvz3CGMLxM2Cq4aUEnLd3ieRCQTOM8Q@mail.gmail.com> (raw)
In-Reply-To: <283E0E80-BDAA-45B4-B627-C7BF44C0D126@cjr.nz>
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
On Sat, Mar 19, 2022 at 11:01 AM Paulo Alcantara <pc@cjr.nz> 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@talpey.com> 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
next prev parent reply other threads:[~2022-03-19 18:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-19 4:23 [PATCH] cifs: fix bad fids sent over wire Steve French
2022-03-19 12:06 ` Tom Talpey
[not found] ` <283E0E80-BDAA-45B4-B627-C7BF44C0D126@cjr.nz>
2022-03-19 18:34 ` Steve French [this message]
2022-03-20 1:22 ` Namjae Jeon
2022-03-20 1:45 ` Tom Talpey
2022-03-20 2:09 ` Steve French
2022-03-21 2:13 ` ronnie sahlberg
2022-03-21 12:05 ` Tom Talpey
2022-03-21 0:20 Paulo Alcantara
2022-03-21 12:10 ` Tom Talpey
2022-03-21 12:30 ` Paulo Alcantara
2022-03-21 12:55 ` Tom Talpey
2022-03-21 15:34 ` Paulo Alcantara
[not found] ` <CAH2r5muAKvWknawHHYPGpAQ7oiQqTEBaskB8taNK0f9msPaHuQ@mail.gmail.com>
2022-03-21 16:46 ` Tom Talpey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAH2r5mv2E=zQ+nVjMuLGvz3CGMLxM2Cq4aUEnLd3ieRCQTOM8Q@mail.gmail.com' \
--to=smfrench@gmail.com \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=pc@cjr.nz \
--cc=tom@talpey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.