[Devel] [PATCH hci-8.1 5/8] ms/mptcp: explicitly drop over memory limits

[Eva Kurchatova <eva.kurchatova@virtuozzo.com>]

From: Paolo Abeni <pabeni@redhat.com>

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 <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-4-dbc1eb853cc3@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(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 <eva.kurchatova@virtuozzo.com>
---
 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