Thread (30 messages) 30 messages, 4 authors, 19d ago

Re: [PATCH net v2 15/15] mptcp: avoid pruning for OoW data

From: Paolo Abeni <pabeni@redhat.com>
Date: 2026-09-09 15:50:08
Also in: lkml, mptcp, stable

On 9/9/26 4:49 PM, netdev-bot+sashiko@kernel.org wrote:
Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 1 · Low: 0

- [Medium] Incomplete realization of the patch's stated principle ("do it
  only when we expect to accept the skb triggering the cleanup"): after…

--

mptcp: avoid pruning for OoW data

This moves the mptcp_try_rmem_schedule() call in mptcp_data_queue_ofo()
so that it runs after the out-of-window check instead of before it, which
avoids running the destructive OoO queue pruning for skbs that are going
to be dropped as out of window.
quoted
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 4309fca6b119..0098e2830931 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -313,12 +313,6 @@ static void mptcp_data_queue_ofo(struct mptcp_sock *msk, struct sk_buff *skb)
 	u64 seq, end_seq, max_seq;
 	struct sk_buff *skb1;
 
-	if (!mptcp_try_rmem_schedule(sk, skb)) {
-		MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_RCVPRUNED);
-		mptcp_drop(sk, skb);
-		return;
-	}
-
 	seq = MPTCP_SKB_CB(skb)->map_seq;
 	end_seq = MPTCP_SKB_CB(skb)->end_seq;
 	max_seq = atomic64_read(&msk->rcv_wnd_sent);
@@ -335,6 +329,12 @@ static void mptcp_data_queue_ofo(struct mptcp_sock *msk, struct sk_buff *skb)
 		return;
 	}
 
+	if (!mptcp_try_rmem_schedule(sk, skb)) {
+		MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_RCVPRUNED);
+		mptcp_drop(sk, skb);
+		return;
+	}
+
[Severity: Medium]
The commit message says pruning should be done "only when we expect
to accept the skb triggering the cleanup".  Does the new placement
fully match that, given the duplicate-data check still happens later in
the rbtree walk of mptcp_data_queue_ofo()?
The change suggested here would add quite a bit of complexity for little
gain, and would diverge MPTCP behavior from TCP. We learned the lesson
the hard way we need very good reasons to do the latter. I'm pretty sure
we are better off with the proposed code.

/P
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help