On Thu, 22 Oct 2020 10:33:31 -0400 Neal Cardwell wrote: > From: Neal Cardwell <ncardw...@google.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. > > Signed-off-by: Neal Cardwell <ncardw...@google.com> > Reported-by: Apollon Oikonomopoulos <apoi...@dmesg.gr> > Tested-by: Apollon Oikonomopoulos <apoi...@dmesg.gr> > Link: https://www.spinics.net/lists/netdev/msg692430.html > Acked-by: Soheil Hassas Yeganeh <soh...@google.com> > Acked-by: Yuchung Cheng <ych...@google.com> > Signed-off-by: Eric Dumazet <eduma...@google.com>
Applied, thanks!
