> -----Original Message----- > From: linux-cifs-owner@xxxxxxxxxxxxxxx [mailto:linux-cifs- > owner@xxxxxxxxxxxxxxx] On Behalf Of Jeff Layton > Sent: Sunday, August 4, 2013 6:19 PM > To: Shirish Pargaonkar > Cc: linux-cifs > Subject: Re: smb2 logoff > > On Sun, 4 Aug 2013 10:51:44 -0500 > Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > > > cifs client does not handle error code returned by smb2 session logoff. > > What if the server returns access denied? > > I looked in ms-smb2 but it does not say anything about how a client > > should handle error by smb2 logoff response. You guys should file a dochelp issue on this. But in general, if the client sends an unsigned request when the server requires a signed one, the request will be failed at the server prior to any processing. If the request is a logoff, that means no logoff occurs. Tom. > > This happens when cifs client sends a smb2 logoff request without a > > signature (because we remove the session from the list before sending > > off a request and handling the response) and can't verify signature in > > the response. > > Also, not sure what happens at the server if the session logoff > > request is a) unsigned and/or b) server returns error as a response. > > > > I think the patch should be to remove the session from the list after > > the smb2 logoff request is sent and response is handled. > > Will submit a patch as part of changing per smb connection key to per > > session key patchset resubmission. > > > > That sounds like the correct approach to me. The only tricky part is to make > sure that new references can't be taken on a session that's being torn down. > > I'd suggest making that change as a separate bugfix patch... > > -- > Jeff Layton <jlayton@xxxxxxxxxx> > -- > To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the > body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at > http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html