Received: by 2002:a25:b323:0:0:0:0:0 with SMTP id l35csp1329211ybj; Fri, 20 Sep 2019 08:43:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqxAO2CDbYG5pXh4Vq6EOS1SOEl41Rt2q6dJAyPMRAtuZBazRxTX9F6CswE6SIuuJs4j+qIn X-Received: by 2002:a17:906:1998:: with SMTP id g24mr9545310ejd.305.1568994237714; Fri, 20 Sep 2019 08:43:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568994237; cv=none; d=google.com; s=arc-20160816; b=wc/HBuy92U/KRTjeWPpEoVImLHnNYgdA8xKMu8jO6p6cS5HQjHnDRMEouLMHssDE8A 07hXz3f8oY9SGW41pE5jHbL464YncNsLv5OAJdvKqs7PTbGioA2BAgm3Ayo5ix7AldJ7 pPdZMY3hQax8e9lxEbvXgQvl6Thy13Eak/dn4ppTf96jIPqshwdh9Y4Vyk5yAwQ3F0DZ lfEwVVfgHqYoCnTOPND71pBVC2R8CF81h/6ZezKtjt4xZAyMZN7HyxNsxAq4FoKO6F6s RY/vUFdEWt85BDm/NCYvjUGP4+q7JLp30aW2h3La6RrpXgC5pvSPL8mOuay3T/vYXZ7A Rn8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=Fye8GSOkwoEgyMjurC38Yvt7cSnLamx1GIvcUsdTXEA=; b=PJLsbXWt5hZOnRcC8lmJ395UejHQiS7yYI+nBbEEWkbVmsM+eqtb6mS02orSHPBhTM r5nYvHS1JOghUnIs8xIeelZxZJKYc7YAR/qGrEHs9XuGQgNNFeHkQlHCiFI/WICpoXkG HGw1EsbJjoSghcEFxekjNqPm9S4Bj1cv18QCwQsAE0Fb2I+CLMkkYXCPk3Rs8JzHoneE 1ZDLRaoduzqjyhGpifyrHkEPbqeKxNzyuDHoYLECOpieaY3DBvUTiVcG/hsqbFcEl5uo wU7s+l0Al43/Tv+eIRnM7ItlOahVQed2e0j+JaOpCiKXov16C1DLTb8rDvIZ0W9qQkty GUoQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=mtn0efHK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id gh16si940617ejb.150.2019.09.20.08.43.34; Fri, 20 Sep 2019 08:43:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=mtn0efHK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393932AbfISW3R (ORCPT + 99 others); Thu, 19 Sep 2019 18:29:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:59154 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2406530AbfISWRw (ORCPT ); Thu, 19 Sep 2019 18:17:52 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 D68702196E; Thu, 19 Sep 2019 22:17:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1568931471; bh=xm2I17chUjyy5gfS9Dzee/XgBwcBHHyXL+dh19MEKrQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mtn0efHKazNigiysasTApGFrLtaSAQAQlcFv9jeN8phzeZpC5+Pa8ByoyCp6E0sFb mkUthZ15DTioSNO2fWaz3F/sK97dQruEPNddtWMXGTBnx5LK1B+ZhADlljaXgIM0MY bYE/mOqaUq26+jw6XE9FjUlLcjNdfZTGkd8aiMno= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , Jason Baron , Vladimir Rutsky , Soheil Hassas Yeganeh , Neal Cardwell , Christoph Paasch Subject: [PATCH 4.14 58/59] tcp: Dont dequeue SYN/FIN-segments from write-queue Date: Fri, 20 Sep 2019 00:04:13 +0200 Message-Id: <20190919214808.429159608@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20190919214755.852282682@linuxfoundation.org> References: <20190919214755.852282682@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Christoph Paasch If a SYN/FIN-segment is on the write-queue, skb->len is 0, but the segment actually has been transmitted. end_seq and seq of the tcp_skb_cb in that case will indicate this difference. We should not remove such segments from the write-queue as we might be in SYN_SENT-state and a retransmission-timer is running. When that one fires, packets_out will be 1, but the write-queue would be empty, resulting in: [ 61.280214] ------------[ cut here ]------------ [ 61.281307] WARNING: CPU: 0 PID: 0 at net/ipv4/tcp_timer.c:429 tcp_retransmit_timer+0x18f9/0x2660 [ 61.283498] Modules linked in: [ 61.284084] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.142 #58 [ 61.285214] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011 [ 61.286644] task: ffffffff8401e1c0 task.stack: ffffffff84000000 [ 61.287758] RIP: 0010:tcp_retransmit_timer+0x18f9/0x2660 [ 61.288715] RSP: 0018:ffff88806ce07cb8 EFLAGS: 00010206 [ 61.289669] RAX: ffffffff8401e1c0 RBX: ffff88805c998b00 RCX: 0000000000000006 [ 61.290968] RDX: 0000000000000100 RSI: 0000000000000000 RDI: ffff88805c9994d8 [ 61.292314] RBP: ffff88805c99919a R08: ffff88807fff901c R09: ffff88807fff9008 [ 61.293547] R10: ffff88807fff9017 R11: ffff88807fff9010 R12: ffff88805c998b30 [ 61.294834] R13: ffffffff844b9380 R14: 0000000000000000 R15: ffff88805c99930c [ 61.296086] FS: 0000000000000000(0000) GS:ffff88806ce00000(0000) knlGS:0000000000000000 [ 61.297523] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 61.298646] CR2: 00007f721da50ff8 CR3: 0000000004014002 CR4: 00000000001606f0 [ 61.299944] Call Trace: [ 61.300403] [ 61.300806] ? kvm_sched_clock_read+0x21/0x30 [ 61.301689] ? sched_clock+0x5/0x10 [ 61.302433] ? sched_clock_cpu+0x18/0x170 [ 61.303173] tcp_write_timer_handler+0x2c1/0x7a0 [ 61.304038] tcp_write_timer+0x13e/0x160 [ 61.304794] call_timer_fn+0x14a/0x5f0 [ 61.305480] ? tcp_write_timer_handler+0x7a0/0x7a0 [ 61.306364] ? __next_timer_interrupt+0x140/0x140 [ 61.307229] ? _raw_spin_unlock_irq+0x24/0x40 [ 61.308033] ? tcp_write_timer_handler+0x7a0/0x7a0 [ 61.308887] ? tcp_write_timer_handler+0x7a0/0x7a0 [ 61.309760] run_timer_softirq+0xc41/0x1080 [ 61.310539] ? trigger_dyntick_cpu.isra.33+0x180/0x180 [ 61.311506] ? ktime_get+0x13f/0x1c0 [ 61.312232] ? clockevents_program_event+0x10d/0x2f0 [ 61.313158] __do_softirq+0x20b/0x96b [ 61.313889] irq_exit+0x1a7/0x1e0 [ 61.314513] smp_apic_timer_interrupt+0xfc/0x4d0 [ 61.315386] apic_timer_interrupt+0x8f/0xa0 [ 61.316129] Followed by a panic. So, before removing an skb with skb->len == 0, let's make sure that the skb is really empty by checking the end_seq and seq. This patch needs to be backported only to 4.14 and older (among those that applied the backport of fdfc5c8594c2). Fixes: fdfc5c8594c2 ("tcp: remove empty skb from write queue in error cases") Cc: Eric Dumazet Cc: Jason Baron Cc: Vladimir Rutsky Cc: Soheil Hassas Yeganeh Cc: Neal Cardwell Signed-off-by: Christoph Paasch Signed-off-by: Greg Kroah-Hartman --- net/ipv4/tcp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -922,7 +922,8 @@ static int tcp_send_mss(struct sock *sk, */ static void tcp_remove_empty_skb(struct sock *sk, struct sk_buff *skb) { - if (skb && !skb->len) { + if (skb && !skb->len && + TCP_SKB_CB(skb)->end_seq == TCP_SKB_CB(skb)->seq) { tcp_unlink_write_queue(skb, sk); tcp_check_send_head(sk, skb); sk_wmem_free_skb(sk, skb);