From patchwork Tue Oct 27 13:48:45 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 313115 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B3031C388F9 for ; Tue, 27 Oct 2020 13:57:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8645721D42 for ; Tue, 27 Oct 2020 13:57:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603807026; bh=nxEgdVTu0E+yKW62PBo15UAWW61PbOMX7JfAGiPFXLQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=BIkq9rxqhC+5bFwSX9bIyokuALQaMeVLkS2Jk/Udcsk8Nowyg8eOnaEX/R5MtzQ1Y GbnnXIC3LngKcpV0lhJDvpurM5IQS08cdhnMgEaUOX1ySXPxn/wZE5tTaX3aS+hPoB e+gPkQq/zHJDfr5g3BeZ1ifHDemRQEdt3jTxlMLo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S368136AbgJ0N5F (ORCPT ); Tue, 27 Oct 2020 09:57:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:43552 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S368131AbgJ0N5E (ORCPT ); Tue, 27 Oct 2020 09:57:04 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AF5D121655; Tue, 27 Oct 2020 13:57:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603807024; bh=nxEgdVTu0E+yKW62PBo15UAWW61PbOMX7JfAGiPFXLQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zg5MFiOXOSngwOkUI/P88FTJ016zgnbfWrQwSXw8JYpp6qjDArgC0GU1P6oxYwsK9 dV0AJw+2w3QIKn8ZZ+xCWasopOo2OyYnuLjfYcQ0C2c+iwkY5AfOLnY4ymvPI6ZzJk UUgNJl25w/jowgd5vwkfeeMRlWMsF0PGd9/TR8BY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Neal Cardwell , Apollon Oikonomopoulos , Soheil Hassas Yeganeh , Yuchung Cheng , Eric Dumazet , Jakub Kicinski Subject: [PATCH 4.4 015/112] tcp: fix to update snd_wl1 in bulk receiver fast path Date: Tue, 27 Oct 2020 14:48:45 +0100 Message-Id: <20201027134901.284182135@linuxfoundation.org> X-Mailer: git-send-email 2.29.1 In-Reply-To: <20201027134900.532249571@linuxfoundation.org> References: <20201027134900.532249571@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Neal Cardwell [ Upstream commit 18ded910b589839e38a51623a179837ab4cc3789 ] 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. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Neal Cardwell Reported-by: Apollon Oikonomopoulos Tested-by: Apollon Oikonomopoulos Link: https://www.spinics.net/lists/netdev/msg692430.html Acked-by: Soheil Hassas Yeganeh Acked-by: Yuchung Cheng Signed-off-by: Eric Dumazet Link: https://lore.kernel.org/r/20201022143331.1887495-1-ncardwell.kernel@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman --- net/ipv4/tcp_input.c | 2 ++ 1 file changed, 2 insertions(+) --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -5531,6 +5531,8 @@ void tcp_rcv_established(struct sock *sk tcp_data_snd_check(sk); if (!inet_csk_ack_scheduled(sk)) goto no_ack; + } else { + tcp_update_wl(tp, TCP_SKB_CB(skb)->seq); } __tcp_ack_snd_check(sk, 0);