2017-06-15 13:43 GMT-07:00 Pavel Shilovskiy <pshilov@xxxxxxxxxxxxx>:
> 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.
Do you have any preferences in a way how above patches should be backported and submitted to stable 3.16.x tree?
--
Best regards,
Pavel Shilovsky