Re: [PATCH] cifs: on send failure, readjust server sequence number downward

[Michael Mol <mikemol-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 3660 bytes --]

On 04/03/2013 03:02 PM, Jeff Layton wrote:
> On Wed, 03 Apr 2013 14:54:42 -0400
> Michael Mol <mikemol-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
>> On 04/03/2013 02:07 PM, Jeff Layton wrote:
>>> If sending a call to the server fails for some reason (for instance, the
>>> sending thread caught a signal), then we must readjust the sequence
>>> number downward again or the next send will have it too high.
>>>
>>> Signed-off-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>> ---
>>>  fs/cifs/smb1ops.c   |  3 +++
>>>  fs/cifs/transport.c | 13 +++++++++++++
>>>  2 files changed, 16 insertions(+)
>>>
>>> diff --git a/fs/cifs/smb1ops.c b/fs/cifs/smb1ops.c
>>> index 23bcd11..3efdb9d 100644
>>> --- a/fs/cifs/smb1ops.c
>>> +++ b/fs/cifs/smb1ops.c
>>> @@ -61,6 +61,9 @@ send_nt_cancel(struct TCP_Server_Info *server, void *buf,
>>>  	 */
>>>  	--server->sequence_number;
>>>  	rc = smb_send(server, in_buf, be32_to_cpu(in_buf->smb_buf_length));
>>> +	if (rc < 0)
>>> +		server->sequence_number--;
>>> +
>>>  	mutex_unlock(&server->srv_mutex);
>>>  
>>>  	cifs_dbg(FYI, "issued NT_CANCEL for mid %u, rc = %d\n",
>>> diff --git a/fs/cifs/transport.c b/fs/cifs/transport.c
>>> index 653bf26..293d2c8 100644
>>> --- a/fs/cifs/transport.c
>>> +++ b/fs/cifs/transport.c
>>> @@ -522,6 +522,9 @@ cifs_call_async(struct TCP_Server_Info *server, struct smb_rqst *rqst,
>>>  	rc = smb_send_rqst(server, rqst);
>>>  	cifs_in_send_dec(server);
>>>  	cifs_save_when_sent(mid);
>>> +
>>> +	if (rc < 0)
>>> +		server->sequence_number -= 2;
>>>  	mutex_unlock(&server->srv_mutex);
>>>  
>>>  	if (rc == 0)
>>> @@ -711,6 +714,8 @@ SendReceive2(const unsigned int xid, struct cifs_ses *ses,
>>>  	cifs_in_send_dec(ses->server);
>>>  	cifs_save_when_sent(midQ);
>>>  
>>> +	if (rc < 0)
>>> +		ses->server->sequence_number -= 2;
>>>  	mutex_unlock(&ses->server->srv_mutex);
>>>  
>>>  	if (rc < 0) {
>>> @@ -835,6 +840,10 @@ SendReceive(const unsigned int xid, struct cifs_ses *ses,
>>>  	rc = smb_send(ses->server, in_buf, be32_to_cpu(in_buf->smb_buf_length));
>>>  	cifs_in_send_dec(ses->server);
>>>  	cifs_save_when_sent(midQ);
>>> +
>>> +	if (rc < 0)
>>> +		ses->server->sequence_number -= 2;
>>> +
>>>  	mutex_unlock(&ses->server->srv_mutex);
>>>  
>>>  	if (rc < 0)
>>> @@ -968,6 +977,10 @@ SendReceiveBlockingLock(const unsigned int xid, struct cifs_tcon *tcon,
>>>  	rc = smb_send(ses->server, in_buf, be32_to_cpu(in_buf->smb_buf_length));
>>>  	cifs_in_send_dec(ses->server);
>>>  	cifs_save_when_sent(midQ);
>>> +
>>> +	if (rc < 0)
>>> +		ses->server->sequence_number -= 2;
>>> +
>>>  	mutex_unlock(&ses->server->srv_mutex);
>>>  
>>>  	if (rc < 0) {
>>>
>>
>> I was re-prioritized...I'll test the patches you'd like me to test just
>> as soon as I can. At that point, I'll prod the list and ask for an
>> up-to-date list of the patchset you'd like me to try.
>>
> 
> This one is current vs. mainline as of today. It'll probably need to be
> backported to RHEL6 though. The other one you'll want to test is commit
> 31efee60f489c75 in the mainline tree. It too will need to be backported
> to rhel6, but that shouldn't be too hard...
> 

Backporting to RHEL6 is going to be "fun". The patched version of 2.6.32
looks only vaguely similar to the context in the patch. It looks like
transport.c in 2.6.32 used cifs_sign_smb{2,} in the places where these
changes are likely to apply.

Unless I'm completely forgetting something I knew a month ago. Ah well.
I'm sure I'll get it figured out; should only require a jaunt through
that file's history.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]