All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paulo Alcantara <pc@cjr.nz>
To: Tom Talpey <tom@talpey.com>,
	linux-cifs@vger.kernel.org, smfrench@gmail.com
Subject: Re: [PATCH] cifs: fix bad fids sent over wire
Date: Mon, 21 Mar 2022 09:30:51 -0300	[thread overview]
Message-ID: <878rt3v66c.fsf@cjr.nz> (raw)
In-Reply-To: <6ef3f7db-a6ed-62c7-226e-b2a20ef5b294@talpey.com>

Tom Talpey <tom@talpey.com> writes:

> On 3/20/2022 8:20 PM, Paulo Alcantara wrote:
>> The client used to partially convert the fids to le64, while storing
>> or sending them by using host endianness.  This broke the client on
>> big-endian machines.  Instead of converting them to le64, store them
>> verbatim and then avoid byteswapping when sending them over wire.
>> 
>> Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
>> ---
>>   fs/cifs/smb2misc.c |  4 ++--
>>   fs/cifs/smb2ops.c  |  8 +++----
>>   fs/cifs/smb2pdu.c  | 53 ++++++++++++++++++++--------------------------
>>   3 files changed, 29 insertions(+), 36 deletions(-)
>> 
>> diff --git a/fs/cifs/smb2misc.c b/fs/cifs/smb2misc.c
>> index b25623e3fe3d..3b7c636be377 100644
>> --- a/fs/cifs/smb2misc.c
>> +++ b/fs/cifs/smb2misc.c
>> @@ -832,8 +832,8 @@ smb2_handle_cancelled_mid(struct mid_q_entry *mid, struct TCP_Server_Info *serve
>>   	rc = __smb2_handle_cancelled_cmd(tcon,
>>   					 le16_to_cpu(hdr->Command),
>>   					 le64_to_cpu(hdr->MessageId),
>> -					 le64_to_cpu(rsp->PersistentFileId),
>> -					 le64_to_cpu(rsp->VolatileFileId));
>> +					 rsp->PersistentFileId,
>> +					 rsp->VolatileFileId);
>
> This conflicts with the statement "store them verbatim". Because the
> rsp->{Persistent,Volatile}FileId fields are u64 (integer) types,
> they are not being stored verbatim, they are being manipulated
> by the CPU load/store instructions. Storing them into a u8[8]
> array is more to the point.

Yes, makes sense.

> If course, if the rsp structure is purely private to the code, then
> the structure element type is similarly private. But a debugger, or
> a future structure reference, may once again get it wrong
>
> Are you rejecting the idea of using a byte array?

No.  That would work, too.  I was just trying to avoid changing a lot of
places and eventually making it harder to backport.

I'll go with the byte array then.

  reply	other threads:[~2022-03-21 12:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-21  0:20 [PATCH] cifs: fix bad fids sent over wire Paulo Alcantara
2022-03-21 12:10 ` Tom Talpey
2022-03-21 12:30   ` Paulo Alcantara [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2022-03-19  4:23 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
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

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=878rt3v66c.fsf@cjr.nz \
    --to=pc@cjr.nz \
    --cc=linux-cifs@vger.kernel.org \
    --cc=smfrench@gmail.com \
    --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.