2017-06-15 0:23 GMT-07:00 Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>:
> On Mon, Jun 12, 2017 at 12:38:35PM -0700, Pavel Shilovsky wrote:
>> From: Sachin Prabhu <sprabhu@xxxxxxxxxx>
>>
>> Commit b8c600120fc8 ("Call echo service immediately after socket
>> reconnect") upstream.
>>
>> Commit 4fcd1813e640 ("Fix reconnect to not defer smb3 session reconnect
>> long after socket reconnect") changes the behaviour of the SMB2 echo
>> service and causes it to renegotiate after a socket reconnect. However
>> under default settings, the echo service could take up to 120 seconds to
>> be scheduled.
>>
>> The patch forces the echo service to be called immediately resulting a
>> negotiate call being made immediately on reconnect.
>>
>> Cc: <stable@xxxxxxxxxxxxxxx> # 3.18.x-4.4.x
>
> Thanks for the backport, now applied.
Thanks.
(adding Ben Hutchings)
I am preparing a backport of this patch for 3.16.x kernel and have a question. This patch (A) was merged into the mainline without a stable tag. After a problem was discovered with the patch, a new patch 62a6cfddcc0a "cifs: Do not send echoes before Negotiate is complete" (B) was merged into the mainline with a stable tag.
This ended up with the patch B merged into stable kernels (nothing bad about it, it does the right things anyway) before the patch A (which is only merged now). Stable tree 3.16 doesn't have both patches A or B. The question is: what is the best way to deal with this situation? I see 3 options here:
a) Send the patch A, then B which matches the mainline order; this results in stable 3.16.x kernel broken between A and B points.
b) Send the patch B, then A which matches other stable trees order.
c) Squash B into A and send one correct patch.
Thoughts?
--
Best regards,
Pavel Shilovsky