Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp477547imm; Fri, 14 Sep 2018 01:16:00 -0700 (PDT) X-Google-Smtp-Source: ANB0Vdab+mrzrRbr9FElZOg5+VA88k7uVcUnf8ZUOm5XVUDZl/lSadTV/gP9c2ainUEYe8CVWXkF X-Received: by 2002:a63:d645:: with SMTP id d5-v6mr10644893pgj.450.1536912960785; Fri, 14 Sep 2018 01:16:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536912960; cv=none; d=google.com; s=arc-20160816; b=NPeX1OLJylmRuk1o9xkLwrdNRVIU773rdar3beJyAH3D5Mo1Ltvm/qMWll//sf1HRY z8L7EX4XS9ALUJYGuF4q1w89jOjobqbetdRNhAWoLzSiMyQARj2s/EqP65Dd6nVuwtgy BX/q45Jq5eB8BmwJeOPGeOSRz7pJniNeia7ls61j1LjahV/OQk59tQwXhnQPOBQx5jd6 Ho7t7yUh9G0KbKhniiyht5SR4JpOhC1cWqvwTWjZ6gdKKfLfo+03+8KkzzEY2RjiBVu+ Bzt+qLnsOBsw34/TOluLO/cauxaefjiPUgT3NJnTiGksbmL9pgFpQZZO6JtY2Rf9fm+H Lx2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:to:from; bh=emAbVm5lFfePV2/XDu9lGIpyWT7xCUaKn2fRni/XOAk=; b=GgOimEEHqWDA8XeraWw7wgDDxwn2LZo+0NoquQei+qxQ1tp1xo6AWsnpW6HmtMYd0o jgL3m1mQECZmudugilhoW+OKjKsRtDvevB96L2vc/vuJ+B/DZ55SY2y5yu7+LStt2d0N l0ytJtKiyLNX+tppBXnExnU1zYkS1JsNXxn9najnut9FmUPJNONz7wKPyk/aatCvmBya xhNvl9eXZy+FQFgC2NZPXuDnOMV8TPqEjpj7kzcbdNSWVocozvNffMLdQrs2PSjohftg 0Ws9nEkNMP8tWH6e0ot2E5J5XLKYoMGD8lC1DvirOi19n3hYKuFjlocuzZ+30kMsC8M5 z6zg== ARC-Authentication-Results: i=1; mx.google.com; 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 l5-v6si7317933pgb.234.2018.09.14.01.15.45; Fri, 14 Sep 2018 01:16:00 -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; 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 S1728095AbeINN1x (ORCPT + 99 others); Fri, 14 Sep 2018 09:27:53 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:12131 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726918AbeINN1w (ORCPT ); Fri, 14 Sep 2018 09:27:52 -0400 Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id A82FB2C337CFF; Fri, 14 Sep 2018 16:14:29 +0800 (CST) Received: from localhost.localdomain.localdomain (10.175.113.25) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.399.0; Fri, 14 Sep 2018 16:14:23 +0800 From: Mao Wenan To: , , , , , , , Subject: [PATCH stable 4.4 V2 3/6] tcp: fix a stale ooo_last_skb after a replace Date: Fri, 14 Sep 2018 16:24:07 +0800 Message-ID: <1536913450-12380-4-git-send-email-maowenan@huawei.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1536913450-12380-1-git-send-email-maowenan@huawei.com> References: <1536913450-12380-1-git-send-email-maowenan@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.175.113.25] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Eric Dumazet [ Upstream commit 76f0dcbb5ae1a7c3dbeec13dd98233b8e6b0b32a ] When skb replaces another one in ooo queue, I forgot to also update tp->ooo_last_skb as well, if the replaced skb was the last one in the queue. To fix this, we simply can re-use the code that runs after an insertion, trying to merge skbs at the right of current skb. This not only fixes the bug, but also remove all small skbs that might be a subset of the new one. Example: We receive segments 2001:3001, 4001:5001 Then we receive 2001:8001 : We should replace 2001:3001 with the big skb, but also remove 4001:50001 from the queue to save space. packetdrill test demonstrating the bug 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 +0 < S 0:0(0) win 32792 +0 > S. 0:0(0) ack 1 +0.100 < . 1:1(0) ack 1 win 1024 +0 accept(3, ..., ...) = 4 +0.01 < . 1001:2001(1000) ack 1 win 1024 +0 > . 1:1(0) ack 1 +0.01 < . 1001:3001(2000) ack 1 win 1024 +0 > . 1:1(0) ack 1 Fixes: 9f5afeae5152 ("tcp: use an RB tree for ooo receive queue") Signed-off-by: Eric Dumazet Reported-by: Yuchung Cheng Cc: Yaogong Wang Signed-off-by: David S. Miller Signed-off-by: Mao Wenan --- net/ipv4/tcp_input.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 7832d0d..4cc0a53 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -4465,7 +4465,7 @@ coalesce_done: NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPOFOMERGE); __kfree_skb(skb1); - goto add_sack; + goto merge_right; } } else if (tcp_try_coalesce(sk, skb1, skb, &fragstolen)) { goto coalesce_done; @@ -4477,6 +4477,7 @@ coalesce_done: rb_link_node(&skb->rbnode, parent, p); rb_insert_color(&skb->rbnode, &tp->out_of_order_queue); +merge_right: /* Remove other segments covered by skb. */ while ((q = rb_next(&skb->rbnode)) != NULL) { skb1 = rb_entry(q, struct sk_buff, rbnode); -- 1.8.3.1