From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.openvz.org (mail.openvz.org [69.168.225.77]) by lore.virtuozzo.com (Postfix) with ESMTPS id D100D81377 for ; Fri, 6 Nov 2026 03:04:36 +0000 (UTC) Received: from mail.openvz.org (localhost [127.0.0.1]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 6A633Mrt012750; Fri, 6 Nov 2026 06:03:23 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 6A633Mrt012750 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="O0lTDyjY" Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 6A6339Hv012703 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Fri, 6 Nov 2026 06:03:09 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 6A6339Hv012703 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-48e0af48c18so165480f8f.2 for ; Thu, 05 Nov 2026 19:03:09 -0800 (PST) X-Gm-Message-State: APuU4Z8hEAxlYYz2+LY5WQKxLwMUlvooFnHYYrj66P7++a5c7vHivT55 EqttRrJFxf94TYZeccrd17fGbXu4WyXbcDQ68M9yyd6TIDx+t2id70Yexigg1b/DWTEU7v+v3O9 6CtC13xbaQbNAZ3vKCYyRW7YsOBATSkph/KQDH3JSQRUslOYlBqK1+w== X-Gm-Gg: AYBFou1ELzs/dmydSqVbWdkzTlpH+fX39+ISLcFWG2yMGerdU33GNn5VKORwdyba5TU g3MnHpDIau24amcSPHSkxpH4x9s06HAw+NUSNifePXoGxGJmQUVrLFiXWPECaRAMthMKZZ0KhxA z6wv830FooblnlmV0z/CnicZkBdg5od9vc3RcrONKoZ09K2Wr3R72iLGt9H99dtVjSDg3Iccrqu iGA2mnGCPCLSfyX0L5hl9RiEHiPQABR4o90v6cxHFvSNh+HwyQCOg1L+l34z+MUKSnnEpMyhYSZ 0qoQ/PUuDNgP2hb+j0m/lFIWmZ7NKQ+MH+ivJ2kbMYKLtc978OQbFEKzrM/LwrsF3GZM5IAG0Gi UcKvMzLxHsc+jxW5qq15+XNum/A== X-Received: by 2002:a05:6000:25f7:b0:491:9fc1:e6c2 with SMTP id ffacd0b85a97d-4927807ea39mr2446278f8f.51.1793934189376; Thu, 05 Nov 2026 19:03:09 -0800 (PST) X-Received: by 2002:a05:6000:25f7:b0:491:9fc1:e6c2 with SMTP id ffacd0b85a97d-4927807ea39mr2446259f8f.51.1793934188918; Thu, 05 Nov 2026 19:03:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1793934188; cv=none; d=google.com; s=arc-20260327; b=YhsudHGO8spA+SEvWKPA1atfVZLfH/8x48+nPngBn8nIeJoARgqf7CXptGgis4e/Zx x6aeFRt7Uw9ZV+fCj1UqPICyuhWXmUgA+90aTQZx9SCsrzBRt3oppysABYBXY5SHycVP 5Ovb3s1h1xig9vsiAmcdmxie1VAyDLNFW2X0zaMJWolYMMTHq9BlrBlZXGxueGsiM4gj Fdr57cmeyxqe6OgEd3TjvsZ6ZuKk1HWq0CaDEl3CC4gvBSJtwX6oIk2WjAFHn70cwJqD pMto8H5aOh7PWBGf2JnjGP6mrLCNQC3X/mK6nQWFcGdPppYDklGQURyR5QVOQ64ifio4 VJnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:dkim-signature; bh=fMpC6JPeJIPPnXNnMObqxz7XU8Pv4RODFfv0iCVzeps=; fh=WpT6aB7RBAGHZeWZzqAr71yzRFbPTYkPWKsRagLn48Q=; b=I/mHtUtzjEwlO20L87+4ApkWJD1X7iB49rXb097984V5x4JWdsiGtzob7LpFvfvJzG 9bLzjE/z1RUga/UIcVw3CNjzST4NMcvOMDu6hx1l4C5YlQxcvgKeihqy0Cl8enjma8KF xr5klwoADccQbmzpVcuc0ceamOCvzIupKFniFsmB8NuFacmI2RSfteTHz9DG9oJlX3iK 6rzdjxlgkdr+d7doKwkZOLohTnl96aLcyPzwKR6RShsWA9I9z7HrkmOiGIbp+hdAX095 E8nTw150R4u7U/sdsye7f9UzA+XX9emxMd0PdkwiAeLHQ5NwiAMWChfSuJ/arXmqOfI0 ldCw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=O0lTDyjY; spf=pass (google.com: domain of eva.kurchatova@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=eva.kurchatova@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: from relay.virtuozzo.com (relay.virtuozzo.com. [130.117.225.111]) by mx.google.com with ESMTPS id ffacd0b85a97d-492fb0e3666si870808f8f.275.2026.11.05.19.03.08 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Nov 2026 19:03:08 -0800 (PST) Received-SPF: pass (google.com: domain of eva.kurchatova@virtuozzo.com designates 130.117.225.111 as permitted sender) client-ip=130.117.225.111; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=O0lTDyjY; spf=pass (google.com: domain of eva.kurchatova@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=eva.kurchatova@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtuozzo.com; s=relay; h=MIME-Version:Message-ID:Date:Subject:From: Content-Type; bh=fMpC6JPeJIPPnXNnMObqxz7XU8Pv4RODFfv0iCVzeps=; b=O0lTDyjY6RA5 BZLT/Z+b50xgWfMQRze7zEbvL/6QVbj0S67/PEsmcta2dQqYmqD8XBMFNZdbLO4Pew+si1rrP2pTe exMREbH2aDgsctkXX4f1ny8jVcS0QHzJKKQ36Arlqhq41iG+vxpDBKr2qzZwqWijEvjpoXALfDVvg hYKwW26klmEJ1XUQfo0SMYM7TS+Mi9sXNAYPBfTKPKHMIUwzFgbOO3JLI197Qsg5cIVzhhB22x4Ix 7ucghk+RYExhq7tctORFQxeKaR2TsYs09o2PEZriAPzEmAP7NWP1fbtbItp3LWjvOfbYNHcrl2dbZ i0mdEwjzhcV7dKqi1Pwpvg==; Received: from ch-vpn.virtuozzo.com ([130.117.225.6] helo=LekKit-T14) by relay.virtuozzo.com with esmtp (Exim 4.96) (envelope-from ) id 1xPAAP-00Gfia-1V; Fri, 06 Nov 2026 04:03:05 +0100 From: Eva Kurchatova To: khorenko@virtuozzo.com Date: Fri, 6 Nov 2026 05:02:11 +0200 Message-ID: <20261106030306.16014-4-eva.kurchatova@virtuozzo.com> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261106030306.16014-1-eva.kurchatova@virtuozzo.com> References: <20261106030306.16014-1-eva.kurchatova@virtuozzo.com> MIME-Version: 1.0 X-OZ-Fwd: true Cc: devel@openvz.org Subject: [Devel] [PATCH hci-8.1 3/8] ms/mptcp: move the stale logic out of retrans scheduler X-BeenThere: devel@openvz.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OpenVZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: devel-bounces@openvz.org Errors-To: devel-bounces@openvz.org From: Paolo Abeni This allow separating the stale logic invocation and the retrans scheduler, and will simplify the next patch. It's also a cleaner design as the retrans scheduler has currently too many side effects. As a possible downside, the retrans work will now traverse the subflows list additional times; that does not matter much, as this is slowpath. While at it, pick more accurate names for the involved helpers and explicitly note that the per subflow stale data is under msk socket lock protection. The scheduler and the stale logic may observe different subflow statues, as no subflow lock is acquired. This is intentional and not harmful, worst case leading to slower retransmissions. Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-2-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski (cherry picked from commit 6cafe51e0f98fe60a106783d30b2f4c4b6039f4c) Rebase note: this tree has no "closing" subflow flag, so only the "stale" bit leaves the bitfield, and __unused grows from 9 to 10. https://virtuozzo.atlassian.net/browse/VSTOR-153491 Feature: fix ms/net Signed-off-by: Eva Kurchatova --- net/mptcp/pm.c | 43 ++++++++++++++++++++++++++++--------------- net/mptcp/protocol.c | 4 ++-- net/mptcp/protocol.h | 11 +++++++---- 3 files changed, 37 insertions(+), 21 deletions(-) diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c index a330e74bf5c1..05775d0b6493 100644 --- a/net/mptcp/pm.c +++ b/net/mptcp/pm.c @@ -908,7 +908,8 @@ bool mptcp_pm_is_backup(struct mptcp_sock *msk, struct sock_common *skc) return mptcp_pm_nl_is_backup(msk, &skc_local); } -static void mptcp_pm_subflows_chk_stale(const struct mptcp_sock *msk, struct sock *ssk) +static void +mptcp_pm_subflow_chk_stale(const struct mptcp_sock *msk, struct sock *ssk) { struct mptcp_subflow_context *iter, *subflow = mptcp_subflow_ctx(ssk); struct sock *sk = (struct sock *)msk; @@ -945,22 +946,34 @@ static void mptcp_pm_subflows_chk_stale(const struct mptcp_sock *msk, struct soc } } -void mptcp_pm_subflow_chk_stale(const struct mptcp_sock *msk, struct sock *ssk) +void mptcp_pm_chk_stale(const struct mptcp_sock *msk) { - struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(ssk); - u32 rcv_tstamp = READ_ONCE(tcp_sk(ssk)->rcv_tstamp); - - /* keep track of rtx periods with no progress */ - if (!subflow->stale_count) { - subflow->stale_rcv_tstamp = rcv_tstamp; - subflow->stale_count++; - } else if (subflow->stale_rcv_tstamp == rcv_tstamp) { - if (subflow->stale_count < U8_MAX) + struct mptcp_subflow_context *subflow; + + mptcp_for_each_subflow(msk, subflow) { + struct sock *ssk = mptcp_subflow_tcp_sock(subflow); + u32 rcv_tstamp; + + if (!__mptcp_subflow_active(subflow)) + continue; + + /* No data outstanding at TCP level? not stale */ + if (tcp_rtx_and_write_queues_empty(ssk)) + continue; + + /* keep track of rtx periods with no progress */ + rcv_tstamp = READ_ONCE(tcp_sk(ssk)->rcv_tstamp); + if (!subflow->stale_count) { + subflow->stale_rcv_tstamp = rcv_tstamp; subflow->stale_count++; - mptcp_pm_subflows_chk_stale(msk, ssk); - } else { - subflow->stale_count = 0; - mptcp_subflow_set_active(subflow); + } else if (subflow->stale_rcv_tstamp == rcv_tstamp) { + if (subflow->stale_count < U8_MAX) + subflow->stale_count++; + mptcp_pm_subflow_chk_stale(msk, ssk); + } else { + subflow->stale_count = 0; + mptcp_subflow_set_active(subflow); + } } } diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 8c17857bbbcf..838b18bc19c9 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2291,7 +2291,6 @@ struct sock *mptcp_subflow_get_retrans(struct mptcp_sock *msk) /* still data outstanding at TCP level? skip this */ if (!tcp_rtx_and_write_queues_empty(ssk)) { - mptcp_pm_subflow_chk_stale(msk, ssk); min_stale_count = min_t(int, min_stale_count, subflow->stale_count); continue; } @@ -2646,9 +2645,10 @@ static void __mptcp_retrans(struct sock *sk) struct mptcp_data_frag *dfrag; int err, len; + mptcp_pm_chk_stale(msk); + mptcp_clean_una_wakeup(sk); - /* first check ssk: need to kick "stale" logic */ err = mptcp_sched_get_retrans(msk); dfrag = mptcp_rtx_head(sk); if (!dfrag) { diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h index 22804ae2e85a..efddbb1920e6 100644 --- a/net/mptcp/protocol.h +++ b/net/mptcp/protocol.h @@ -530,12 +530,11 @@ struct mptcp_subflow_context { send_infinite_map : 1, remote_key_valid : 1, /* received the peer key from */ disposable : 1, /* ctx can be free at ulp release time */ - stale : 1, /* unable to snd/rcv data, do not use for xmit */ valid_csum_seen : 1, /* at least one csum validated */ is_mptfo : 1, /* subflow is doing TFO */ close_event_done : 1, /* has done the post-closed part */ mpc_drop : 1, /* the MPC option has been dropped in a rtx */ - __unused : 9; + __unused : 10; bool data_avail; bool scheduled; bool pm_listener; /* a listener managed by the kernel PM? */ @@ -553,7 +552,11 @@ struct mptcp_subflow_context { u8 reset_seen:1; u8 reset_transient:1; u8 reset_reason:4; - u8 stale_count; + u8 stale_count; /* Protected by the msk socket lock */ + u8 stale; /* Protected by the msk socket lock, + * if set the subflow is unable to snd/rcv + * data, the schedule should skip it + */ u32 subflow_id; @@ -1004,7 +1007,7 @@ int mptcp_pm_parse_entry(struct nlattr *attr, struct genl_info *info, bool mptcp_pm_addr_families_match(const struct sock *sk, const struct mptcp_addr_info *loc, const struct mptcp_addr_info *rem); -void mptcp_pm_subflow_chk_stale(const struct mptcp_sock *msk, struct sock *ssk); +void mptcp_pm_chk_stale(const struct mptcp_sock *msk); void mptcp_pm_new_connection(struct mptcp_sock *msk, const struct sock *ssk, int server_side); void mptcp_pm_fully_established(struct mptcp_sock *msk, const struct sock *ssk); bool mptcp_pm_allow_new_subflow(struct mptcp_sock *msk); -- 2.56.0 _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel