[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201022090757.4ac6ba0f@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date: Thu, 22 Oct 2020 09:07:57 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Neal Cardwell <ncardwell.kernel@...il.com>
Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
Neal Cardwell <ncardwell@...gle.com>,
Apollon Oikonomopoulos <apoikos@...sg.gr>,
Soheil Hassas Yeganeh <soheil@...gle.com>,
Yuchung Cheng <ycheng@...gle.com>,
Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH net] tcp: fix to update snd_wl1 in bulk receiver fast
path
On Thu, 22 Oct 2020 10:33:31 -0400 Neal Cardwell wrote:
> From: Neal Cardwell <ncardwell@...gle.com>
>
> In the header prediction fast path for a bulk data receiver, if no
> data is newly acknowledged then we do not call tcp_ack() and do not
> call tcp_ack_update_window(). This means that a bulk receiver that
> receives large amounts of data can have the incoming sequence numbers
> wrap, so that the check in tcp_may_update_window fails:
> after(ack_seq, tp->snd_wl1)
>
> If the incoming receive windows are zero in this state, and then the
> connection that was a bulk data receiver later wants to send data,
> that connection can find itself persistently rejecting the window
> updates in incoming ACKs. This means the connection can persistently
> fail to discover that the receive window has opened, which in turn
> means that the connection is unable to send anything, and the
> connection's sending process can get permanently "stuck".
>
> The fix is to update snd_wl1 in the header prediction fast path for a
> bulk data receiver, so that it keeps up and does not see wrapping
> problems.
>
> This fix is based on a very nice and thorough analysis and diagnosis
> by Apollon Oikonomopoulos (see link below).
>
> This is a stable candidate but there is no Fixes tag here since the
> bug predates current git history. Just for fun: looks like the bug
> dates back to when header prediction was added in Linux v2.1.8 in Nov
> 1996. In that version tcp_rcv_established() was added, and the code
> only updates snd_wl1 in tcp_ack(), and in the new "Bulk data transfer:
> receiver" code path it does not call tcp_ack(). This fix seems to
> apply cleanly at least as far back as v3.2.
In that case - can I slap:
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
on it?
Powered by blists - more mailing lists