Received: by 2002:a05:6358:111d:b0:dc:6189:e246 with SMTP id f29csp1629662rwi; Thu, 3 Nov 2022 07:26:00 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5ILpqnGJU8CTGLU3FrYai3SCnpuXyMLZqei7SAEOyBRFs5onZSTS3/B7+E81WDxHPo7yeb X-Received: by 2002:a17:907:8a20:b0:7ad:e0cf:417e with SMTP id sc32-20020a1709078a2000b007ade0cf417emr18848495ejc.17.1667485560120; Thu, 03 Nov 2022 07:26:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667485560; cv=none; d=google.com; s=arc-20160816; b=E7oNsl9S6uWDvWMWVfnVxXxsemKhfp769avxUM8Y+WhtJX304h5g0jYeoD4LuU9aZE 2DjcfWbXrxp66QIgb6HCreonL7swJMJH2j4WDXZWp29G6nYElwD31vr9U2sGuKJDoIeX 12XQNLfQuAnmLfp5Ak10vv6USGDETeks+EQLr9owxMCCzZzF6n0EMHDn3v21ZIOCoe/b R9fE4k3ahsuWybUdBjL2QluWMLbkBGGa1p/6IMkmxZY4UcXYEMrdiKYJhSB+wrA7dC5w G6/+C3hZaL24QPkYdu43wLQlJq3H7qyfvr9/qqpqbRQx3fDQ0Yc0l8mKzYhN0S0navvl Dytw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=kSrCH0Te60lbObeyJlysAcGRAtRbK8J7JgguatyqHwc=; b=IU11EgAPXl4OEBzZdmH65kylBerpJGexi7adjpt1dm9qreCPB8rmOvmfk11q93toUd Yt2X4hzFZCMGTtgkTj6GNb8xeKz/0eZ9fc1YCyPpzgXKdQbRT9Wg3IAhtcPaYKdETjpz apkREMGcROZUgNwcpm1FlGf+WVw/9uI4c0QKFhbSniRXvRcofwmSnMxh81WaWYgg6MT3 CCQrED+2epIHsaDiEGcmyomB911VHhVuLxsvt0Ubpk8Q4oHfMKCRswR9L91d9xpHsFo8 eXXVEb9UbP0D/sqhBXHJnJ1qwY6H9gTdo8FW5nq/eMiQwhE2fJuA5vniQxOFsKSKpo7E 3TwQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=fumuVICZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q14-20020a056402518e00b0045c7c7b95easi1001407edd.73.2022.11.03.07.25.36; Thu, 03 Nov 2022 07:26:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=fumuVICZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229699AbiKCOKn (ORCPT + 98 others); Thu, 3 Nov 2022 10:10:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33664 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230157AbiKCOKj (ORCPT ); Thu, 3 Nov 2022 10:10:39 -0400 Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6116710569 for ; Thu, 3 Nov 2022 07:10:38 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id l42-20020a9d1b2d000000b0066c6366fbc3so1038161otl.3 for ; Thu, 03 Nov 2022 07:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kSrCH0Te60lbObeyJlysAcGRAtRbK8J7JgguatyqHwc=; b=fumuVICZFRS+xFIUyKjkj88RoqF2ee/MllqYEj4nzltfVlDwe6hT9/Cpgcudyme6TV ws0vJik5LjFez9vkOZV24gGiwC1EwukZpeXL4G5j9jrGj/k4XmrKgIiYDtUgyTo2MB3w XRZkrOxFOwqfgHC8howIX86XjTGtACYP4eCn3IlSMW6t67fiPI9uvElAWF0MS6BKHBHp oILSWwdyhSgPcwDuRPsEFTMIt0Dd5a2P2812+cUscXJppkG7dwwuJmZp2AaeC5A3Pvfo Ufs2MPJhfIcX2oRMLzhYs4YB47Y55BVW+3j03BMBL/mFoah64SqKhSO+MyUXF1ZVcbuB 5r3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kSrCH0Te60lbObeyJlysAcGRAtRbK8J7JgguatyqHwc=; b=1G3t3yiAZCfkkPclIgtLiRuf3X0zaZcXTeqdsZ2hdv2HbXrVb8HEyxDtbSrS+tCqFZ IjviG2GF4eh80skWEZIlracm/1FtNkyS0ukV7DHEkLgQTgI70SmGxCvEFFAtiF8TWIOh 9i5fgemdBX6FOEKS0D0xABegRFWCZyFWPDM1yTA944A1VDlKIot0eheiBJMIG/7GVvR6 KMnqEJdjhlFu/+XVIAg4h5qUW3nPWbb33yLu3Muo7gsko/ahm36JmFy7LbvJejMkt3T0 5wr3wnBnqiHBYn9058DvOyc29HFpaEH97Cy/MLROozS//WxqEi54e8Z3KZLkLNC8e3Wb du5Q== X-Gm-Message-State: ACrzQf2pegRm6X76nwS7Xv8f9YwW5Fv1pRbHYhRAVrNPP5ufDrXlQ44K jcCSRfx6DaN4eXLDQsCtp+VOzMlcTRminT/N4MiPwA== X-Received: by 2002:a05:6830:1343:b0:66c:57c4:f4c4 with SMTP id r3-20020a056830134300b0066c57c4f4c4mr9929276otq.161.1667484637488; Thu, 03 Nov 2022 07:10:37 -0700 (PDT) MIME-Version: 1.0 References: <20221103124652.260085-1-luwei32@huawei.com> In-Reply-To: <20221103124652.260085-1-luwei32@huawei.com> From: Neal Cardwell Date: Thu, 3 Nov 2022 10:10:20 -0400 Message-ID: Subject: Re: [patch net v4] tcp: prohibit TCP_REPAIR_OPTIONS if data was already sent To: Lu Wei Cc: edumazet@google.com, davem@davemloft.net, yoshfuji@linux-ipv6.org, dsahern@kernel.org, kuba@kernel.org, pabeni@redhat.com, xemul@parallels.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 3, 2022 at 7:42 AM Lu Wei wrote: > > If setsockopt with option name of TCP_REPAIR_OPTIONS and opt_code > of TCPOPT_SACK_PERM is called to enable sack after data is sent > and dupacks are received , it will trigger a warning in function > tcp_verify_left_out() as follows: > > ============================================ > WARNING: CPU: 8 PID: 0 at net/ipv4/tcp_input.c:2132 > tcp_timeout_mark_lost+0x154/0x160 > tcp_enter_loss+0x2b/0x290 > tcp_retransmit_timer+0x50b/0x640 > tcp_write_timer_handler+0x1c8/0x340 > tcp_write_timer+0xe5/0x140 > call_timer_fn+0x3a/0x1b0 > __run_timers.part.0+0x1bf/0x2d0 > run_timer_softirq+0x43/0xb0 > __do_softirq+0xfd/0x373 > __irq_exit_rcu+0xf6/0x140 > > The warning is caused in the following steps: > 1. a socket named socketA is created > 2. socketA enters repair mode without build a connection > 3. socketA calls connect() and its state is changed to TCP_ESTABLISHED > directly > 4. socketA leaves repair mode > 5. socketA calls sendmsg() to send data, packets_out and sack_outs(dup > ack receives) increase > 6. socketA enters repair mode again > 7. socketA calls setsockopt with TCPOPT_SACK_PERM to enable sack > 8. retransmit timer expires, it calls tcp_timeout_mark_lost(), lost_out > increases > 9. sack_outs + lost_out > packets_out triggers since lost_out and > sack_outs increase repeatly > > In function tcp_timeout_mark_lost(), tp->sacked_out will be cleared if > Step7 not happen and the warning will not be triggered. As suggested by > Denis and Eric, TCP_REPAIR_OPTIONS should be prohibited if data was > already sent. So this patch checks tp->segs_out, only TCP_REPAIR_OPTIONS > can be set only if tp->segs_out is 0. This last sentence mentioning tp->segs_out has not been updated to match the code. :-) You may want to just omit that sentence, since it is just restating the patch in English prose, and the previous sentence already conveys the the intent and high-level functionality ("TCP_REPAIR_OPTIONS should be prohibited if data was already sent"). neal