On Tue, Jan 02, 2018 at 02:11:25PM -0500, Neal Cardwell wrote:
> On Tue, Jan 2, 2018 at 1:32 PM, David Miller <davem@xxxxxxxxxxxxx> wrote:
> > From: Neal Cardwell <ncardwell@xxxxxxxxxx>
> > Date: Tue, 2 Jan 2018 11:57:59 -0500
> >
> >> On Mon, Jan 1, 2018 at 9:31 AM, Greg Kroah-Hartman
> >> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >>> This is the start of the stable review cycle for the 4.9.74 release.
> >>> There are 75 patches in this series, all will be posted as a response
> >>> to this one. If anyone has any issues with these being applied, please
> >>> let me know.
> >>>
> >>> Responses should be made by Wed Jan 3 14:00:03 UTC 2018.
> >>> Anything received after that time might be too late.
> >>>
> >>> The whole patch series can be found in one patch at:
> >>> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.74-rc1.gz
> >>> or in the git tree and branch at:
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
> >>> and the diffstat can be found below.
> >>
> >> Hi Greg,
> >>
> >> In looking at the 4.9 and 4.14 patches yesterday, I noticed there were
> >> two TCP BBR fixes that made it into 4.14 but not 4.9. Doing an
> >> inventory of the TCP BBR fixes, AFAICT we have:
> >>
> >> c589e69b508d tcp_bbr: record "full bw reached" decision in new
> >> full_bw_reached bit
> >> - in 4.9 and 4.14 (great)
> >>
> >> 2f6c498e4f15 tcp_bbr: reset full pipe detection on loss recovery undo
> >> - in 4.14 (but not 4.9)
> >>
> >> 600647d467c6 tcp_bbr: reset long-term bandwidth sampling on loss recovery undo
> >> - in 4.14 (but not 4.9)
> >>
> >> Lacking the second and third patches in 4.9 will not cause any new
> >> problems, but it will miss out on some nice fixes. If it's possible to
> >> get 2f6c498e4f15 and 600647d467c6 either into 4.9.74 or 4.9.75, I
> >> would be very grateful.
> >
> > These were not straight-forward to backport and I felt the risk outweighed
> > the gains.
> >
> > If you want to do the backport yourself and you feel confident in it,
> > feel free.
>
> Thanks, Greg and David. Looks like these 2 patches will cherry-pick
> cleanly if cherry-picked in the following sequence, on top of
> 4.9.74-rc1, which already has 6c9e73ef9aa7 ("tcp_bbr: record "full bw
> reached" decision in new full_bw_reached bit"):
>
> $ git checkout linux-stable-rc/linux-4.9.y
>
> $ git cherry-pick 2f6c498e4f15
> Performing inexact rename detection: 100% (17803152/17803152), done.
> [detached HEAD 0982234c57e1] tcp_bbr: reset full pipe detection on
> loss recovery undo
> Date: Thu Dec 7 12:43:31 2017 -0500
> 1 file changed, 4 insertions(+)
>
> $ git cherry-pick 600647d467c6
> Performing inexact rename detection: 100% (17803152/17803152), done.
> [detached HEAD 7e866eccd083] tcp_bbr: reset long-term bandwidth
> sampling on loss recovery undo
> Date: Thu Dec 7 12:43:32 2017 -0500
> 1 file changed, 1 insertion(+)
>
> $ git log --oneline --decorate | head -3
> 7e866eccd083 (HEAD) tcp_bbr: reset long-term bandwidth sampling on
> loss recovery undo
> 0982234c57e1 tcp_bbr: reset full pipe detection on loss recovery undo
> 79070be7f1ae (linux-stable-rc/linux-4.9.y) Linux 4.9.74-rc1
>
> I verified that this compiles without warnings, and boots, and BBR works.
>
> Shall I prepare another version of these 2 patches, or do we think
> this recipe will be sufficient? (Sorry I am not more familiar with the
> backport-to-stable process.)
That works, those two patches are now queued up for the next stable
release, thanks!
greg k-h