---------- Forwarded message --------- From: Steve French <smfrench@xxxxxxxxx> Date: Wed, Aug 30, 2023 at 9:02 AM Subject: Re: [PATCH][SMB client] send ChannelSequence number after reconnect To: Shyam Prasad N <nspmangalore@xxxxxxxxx> Cc: CIFS <linux-cifs@xxxxxxxxxxxxxxx>, Tom Talpey <tom@xxxxxxxxxx>, Bharath S M <bharathsm@xxxxxxxxxxxxx>, Aurélien Aptel <aaptel@xxxxxxxxx> we could do a follow on with your suggestion, but seems like without the replay flag would just look like a new write to the same offset (which should take precedence over an older queued write to the same offset that has a lower sequence number) I will code up a follow on patch to do replay operation patch On Wed, Aug 30, 2023 at 8:56 AM Shyam Prasad N <nspmangalore@xxxxxxxxx> wrote: > > On Fri, Aug 25, 2023 at 10:09 AM Steve French <smfrench@xxxxxxxxx> wrote: > > > > The ChannelSequence field in the SMB3 header is supposed to be > > increased after reconnect to allow the server to distinguish > > requests from before and after the reconnect. We had always > > been setting it to zero. There are cases where incrementing > > ChannelSequence on requests after network reconnects can reduce > > the chance of data corruptions. > > > > See MS-SMB2 3.2.4.1 and 3.2.7.1 > > > > Note that (as Tom Talpey pointed out) a macro "CIFS_SERVER_IS_CHAN" used by this patch is confusing (has a confusing name) since multichannel is not supported for older dialects like CIFS. I will fix that macro name in a followon patch. > > > > -- > > Thanks, > > > > Steve > > Theoretically seems okay. Although MS-SMB2 says that replay requests > need to be indicated as replay in the header, which we are not doing > currently. > I don't know what maybe a side effect of not sending that could be. > Will this patch without that make things worse? > > -- > Regards, > Shyam -- Thanks, Steve -- Thanks, Steve
