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 B8DA28139E for ; Fri, 6 Nov 2026 03:04:48 +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 6A633TdH012776; Fri, 6 Nov 2026 06:03:30 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 6A633TdH012776 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="RjbkfO39" 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 6A633A7Q012711 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Fri, 6 Nov 2026 06:03:10 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 6A633A7Q012711 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-48e1ad3cb66so100222f8f.3 for ; Thu, 05 Nov 2026 19:03:10 -0800 (PST) X-Gm-Message-State: APuU4Z8zsWsBw61ggcg2y4qffkVEfb5NUIrpjVXQgibe0wSlyeGMTv/v NolNl3oNJ5d0/Di4XpgENlydibKued7ygaHEWkHGXVpI8N4S7r508TxUnl+jyGhrP7cgEfZWQ+X TFjf7Nwe/mech+fukEt0FE7P8BTv7BaGKuO3f3PLCYYjhLztW414RIw== X-Gm-Gg: AYBFou1XOxO1oQVVORaO88QLYj0MTuW9lxaZoth84AjHpEOuXVe23xbVDvDywnAzE8X Qxt16tgI8QkOncd9Weh8/l72AWFHNyfeo1B/rZDXI0u8QG2uxSjWaI/ocIg+Mvrl/nEOajUnCtB uv4Hcaia9fshoRYjEUIHWCf8hPJKp5KdCF+sIpJQcpRyl49TLbgdQbanVZt0fhfadmq5AIRRoW2 I3yRfkfVIxEAFIQDfpJLBJAMB0Q4bVkA1Oq3++9cEK9zgmR6EQuwMdcSBdmwlvHnOl86P/ywpG6 PPSjcE4pR1Fr7dAJD4XA2HlH8XqM0L3esuIYFCFrvS5ph0Pn4p5/+jGSCNG7nb8Wohm2HXW70lq C8+TMvNeDYVr7JLyAXnshwPum X-Received: by 2002:a05:6000:25ea:b0:48d:f39b:83de with SMTP id ffacd0b85a97d-492732dc7edmr2591356f8f.3.1793934189938; Thu, 05 Nov 2026 19:03:09 -0800 (PST) X-Received: by 2002:a05:6000:25ea:b0:48d:f39b:83de with SMTP id ffacd0b85a97d-492732dc7edmr2591324f8f.3.1793934189429; Thu, 05 Nov 2026 19:03:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1793934189; cv=none; d=google.com; s=arc-20260327; b=VlUW+UX6VofnqnKn+FSREJRBtc1fzoWdXJU91nyaVu4lT+CBy9qOd5Yyrw8CEwuC85 vXuNrK9T++zB1+nPbWkpA6qTv1+64V59LRlw+vNmjWVJaGeDJBJLFQB/hSe6corNU2Qu TbFbSbEg92s3nYORBQ4niojY3oQ8rSB7+eTbwQE43bSMP3K1VDxXD9Wi+rMVndxQLkyT +Bf70EGzUaaZ3uyDm5Ffg/s9NoP3GJzrLO9sxl6nVEOORuhs23GWm7E48nxXyi82XXU7 d0aiZdJfCc22thiS/ELeT10G0sHawwbxuhOMdmSUdPacMyHYl2BrxkMlTUh6/PczILvS gs5Q== 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=u1nzAfmLShJIQj5+R/km/PFe2KFIAWbsO1p4duPrrHo=; fh=WpT6aB7RBAGHZeWZzqAr71yzRFbPTYkPWKsRagLn48Q=; b=kYtRK8FCa9dN/M/x0uNxIEAZK8AwEVhnElFBJcMQqxwdtktIeirYjeqBRzC9mVrz85 uotxZ0zLRPppdoZc+lIrFAe6I3eOFMiHfJXiEMAkvujrL/7QguN/q3cWQz10ZAsQv/te qAg4cHTWVCBaNO6Wvr1/8x6MFs+RrWayorVXvOPgDFMNM133ddS0F5z6VaM6eLmqOcu9 evENTpTUrFmWTd6xYJ7HFqJ5ERiGpqr/GtHPyPzf2r84dw5bAWRIvWk08U9s9YC0SYbH HNeKUShfEpkBzgL+sy6pCLxi3edBrnLGqscCHKX3vzBIv6ncobwG+XfXIhbFGHkTslyJ OeOQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=RjbkfO39; 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-492d7ad9a48si1060636f8f.329.2026.11.05.19.03.09 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Nov 2026 19:03:09 -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=RjbkfO39; 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=u1nzAfmLShJIQj5+R/km/PFe2KFIAWbsO1p4duPrrHo=; b=RjbkfO391DQ0 pvssP7/ZVSXwuAhYwIBwC9/2mN5QjcnBueXyEFOb8auxMkaTlMxfnyWYYlm7Ce3N/QirCqPp/yGNI SFWGHf3vv70vMyD4eSfRikoWlEWvdLjtYDoAElRB/s2g5khePbhA8bk/8xkEM/agWUiniwO7EmFDI tPd7SY6c6zRMY2cb5ThTWlPjsbk93tJLx1Ih5ozicP60gwJF5QRqqWKPT6R5cqzBckblSTWX5fBhj 8hTem35dJkWSZIUkIMyn23hy1CM/iVVE20OqOjwfLnFD2kngdXdaTfntJK1PZg3PCF27K3sZLMufn KfJ+Y3psZ86muU8FQleKNQ==; 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-36; Fri, 06 Nov 2026 04:03:06 +0100 From: Eva Kurchatova To: khorenko@virtuozzo.com Date: Fri, 6 Nov 2026 05:02:13 +0200 Message-ID: <20261106030306.16014-6-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 5/8] ms/mptcp: explicitly drop over memory limits 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 Currently the enforcement of the rcvbuf constraint is implemented when moving the skbs into the msk receive or OoO queue, keeping the incoming skbs in the subflow queue when over limits. Under significant memory pressure the above can cause permanent data transfer stalls, as the skb needed to make forward progress can be stuck in a subflow queue. Over memory limits, drop the incoming skb, relying on MPTCP-level retransmissions. Note that fallback socket must perform the limit before the skb reaches the subflow-level queue, as dropping an in-sequence already acked skb would break the stream. This is not a complete fix for the stall issue, as the drop strategy needs refinements that will come in the next patches. 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-4-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski (cherry picked from commit e0e4d56b050597a690b4dd1c281af532469b0636) Rebase note: this tree has no MPTCP-level backlog, its receive path moves the skbs from the subflow queue straight to the msk. The drop goes into __mptcp_move_skb(), and the loops that move the skbs stop over the limits only for a fallback socket, which keeps them in the subflow queue as before. The options.c check that drops them for a fallback socket before that queue, and the BacklogDrop counter, are left out; RcvPruned is already there. https://virtuozzo.atlassian.net/browse/VSTOR-153491 Feature: fix ms/net Signed-off-by: Eva Kurchatova --- net/mptcp/protocol.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 2dcce47a1ef7..6e8779646d17 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -286,6 +286,15 @@ static bool __mptcp_move_skb(struct mptcp_sock *msk, struct sock *ssk, skb_ext_reset(skb); skb_orphan(skb); + /* Can't drop packets for fallback socket this late, or the stream + * will break. + */ + if (unlikely(sk_rmem_alloc_get(sk) > READ_ONCE(sk->sk_rcvbuf)) && + !__mptcp_check_fallback(msk)) { + MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_RCVPRUNED); + goto drop; + } + /* try to fetch required memory from subflow */ if (!sk_rmem_schedule(sk, skb, skb->truesize)) { MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_RCVPRUNED); @@ -599,7 +608,8 @@ static bool __mptcp_move_skbs_from_subflow(struct mptcp_sock *msk, struct sk_buff *skb; bool fin; - if (sk_rmem_alloc_get(sk) > sk->sk_rcvbuf) + if (__mptcp_check_fallback(msk) && + sk_rmem_alloc_get(sk) > sk->sk_rcvbuf) break; /* try to move as much data as available */ @@ -2078,11 +2088,11 @@ static bool __mptcp_move_skbs(struct sock *sk) struct sock *ssk; bool slowpath; - /* - * As an optimization avoid traversing the subflows list - * and ev. acquiring the subflow socket lock before baling out + /* Over the limits a fallback socket leaves the data in the + * subflows, don't loop on them */ - if (sk_rmem_alloc_get(sk) > sk->sk_rcvbuf) + if (__mptcp_check_fallback(msk) && + sk_rmem_alloc_get(sk) > sk->sk_rcvbuf) break; subflow = __mptcp_first_ready_from(msk, subflow); -- 2.56.0 _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel