Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2336343ybz; Thu, 23 Apr 2020 16:15:48 -0700 (PDT) X-Google-Smtp-Source: APiQypLgowJ7MgaC3nK9CB59UWLxoA36DCdMPOa/DkVEJhnl9NK8P8VBBQkCyJayFQCMXgMHpgJc X-Received: by 2002:a17:906:4e8a:: with SMTP id v10mr4549669eju.63.1587683747993; Thu, 23 Apr 2020 16:15:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587683747; cv=none; d=google.com; s=arc-20160816; b=GRtDBAMgcYMTyE/nH9a5bXCfBmIoz2tPJyDAZj3D37NtyXaP0YbMPfX/oEb9Ln5uay J3pI7/Y2YQ/5vo4lMIvTu6yiH5PVbP/5pZ0HmVJhZjUGwc2E/Ai8ixShXU5S/eaaP619 1TiFrwTemjyMthb5tueBX+iWShSgtzOZY/mq5aPrXuMe8lDQIbMULC38pgPcepPxpgni 5+NP2NdOWy3PTNBCxZ0rAZfIF93u07j/6TRDn+4xKvfmqKOFki8KqP8YGce2QKJgbAHj G2i3aEVWNSilOAP2fq8UMLG4+iwv43aOf9eMpalIWvlTZkzHe3naL2kbfZ9FygJHv+zm kixw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=K9Rqpe887yzif5D2VPUILdNFIuRPT0bjm7YyDk/d7O8=; b=HrEmIyusq8j0oOUFuguYwXUO8BUXZ47WRILY8vBHbvczLjbkTOGIJw1dMVAp6+Gdbz R7UD+FKeUNTnb8SzdFUZvxokKIFpjTzPyV5YuUZ149aXh9f1xqbqmbAETsNV1pKcpFGE i/you5xELo/dKP6Uyemvgo7USHBMXv6kl0opUnOl6jQJ9CME1pZ5e0MNt5fzgWBwfckA +wO5YxDTrJ9EGs9gkdTACadclhUtKWyERhpFVuxIj26dEO8SaghMoPZ8vquXyvx6/Xt1 DpwyPOJ0LyeWJ7OScdEDbnpLdRU7wXJZ8Ls9AZiMXObJWJTdo5nKJM5wZzhddp6J5QXi gGmw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h59si2110197edc.222.2020.04.23.16.15.24; Thu, 23 Apr 2020 16:15:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728995AbgDWXM4 (ORCPT + 99 others); Thu, 23 Apr 2020 19:12:56 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:50016 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728498AbgDWXGv (ORCPT ); Thu, 23 Apr 2020 19:06:51 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jRkvT-0004if-Jp; Fri, 24 Apr 2020 00:06:35 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvR-00E6pB-9V; Fri, 24 Apr 2020 00:06:33 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, Denis Kirjanov , "Christoph Paasch" , "Soheil Hassas Yeganeh" , "Neal Cardwell" , "Eric Dumazet" , "Jakub Kicinski" , "Jason Baron" Date: Fri, 24 Apr 2020 00:05:53 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 126/245] tcp: do not send empty skb from tcp_write_xmit() In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.83-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Eric Dumazet commit 1f85e6267caca44b30c54711652b0726fadbb131 upstream. Backport of commit fdfc5c8594c2 ("tcp: remove empty skb from write queue in error cases") in linux-4.14 stable triggered various bugs. One of them has been fixed in commit ba2ddb43f270 ("tcp: Don't dequeue SYN/FIN-segments from write-queue"), but we still have crashes in some occasions. Root-cause is that when tcp_sendmsg() has allocated a fresh skb and could not append a fragment before being blocked in sk_stream_wait_memory(), tcp_write_xmit() might be called and decide to send this fresh and empty skb. Sending an empty packet is not only silly, it might have caused many issues we had in the past with tp->packets_out being out of sync. Fixes: c65f7f00c587 ("[TCP]: Simplify SKB data portion allocation with NETIF_F_SG.") Signed-off-by: Eric Dumazet Cc: Christoph Paasch Acked-by: Neal Cardwell Cc: Jason Baron Acked-by: Soheil Hassas Yeganeh Signed-off-by: Jakub Kicinski [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings --- net/ipv4/tcp_output.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -1992,6 +1992,14 @@ static bool tcp_write_xmit(struct sock * unlikely(tso_fragment(sk, skb, limit, mss_now, gfp))) break; + /* Argh, we hit an empty skb(), presumably a thread + * is sleeping in sendmsg()/sk_stream_wait_memory(). + * We do not want to send a pure-ack packet and have + * a strange looking rtx queue with empty packet(s). + */ + if (TCP_SKB_CB(skb)->end_seq == TCP_SKB_CB(skb)->seq) + break; + TCP_SKB_CB(skb)->when = tcp_time_stamp; if (unlikely(tcp_transmit_skb(sk, skb, 1, gfp)))