On Thu, 22 Oct 2020 10:33:31 -0400 Neal Cardwell wrote:
> From: Neal Cardwell <[email protected]>
>
> 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?
