* [PATCH v2] mptcp: do not drop partial packets
@ 2026-04-22 14:39 Shardul Bankar
2026-04-22 17:03 ` Matthieu Baerts
2026-04-24 13:20 ` Simon Horman
0 siblings, 2 replies; 4+ messages in thread
From: Shardul Bankar @ 2026-04-22 14:39 UTC (permalink / raw)
To: pabeni, matttbe, martineau
Cc: geliang, davem, edumazet, kuba, horms, netdev, mptcp,
linux-kernel, janak, kalpan.jani, shardulsb08, Shardul Bankar
When a packet arrives with map_seq < ack_seq < end_seq, the beginning
of the packet has already been acknowledged but the end contains new
data. Currently the entire packet is dropped as "old data," forcing
the sender to retransmit.
Instead, skip the already-acked bytes by adjusting the skb offset and
enqueue only the new portion. Update bytes_received and ack_seq to
reflect the new data consumed.
A previous attempt at this fix (commit 1d2ce718811a ("mptcp: do not
drop partial packets"), reverted in commit bf39160c4218 ("Revert
"mptcp: do not drop partial packets"")) also added a zero-window
check and changed rcv_wnd_sent initialization, which caused test
regressions. This version addresses only the partial packet handling
without modifying receive window accounting.
Fixes: ab174ad8ef76 ("mptcp: move ooo skbs into msk out of order queue.")
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/600
Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
---
v2: Drop the mptcp_try_coalesce() attempt for partial packets, since
non-zero offset always prevents coalescing (Paolo).
net/mptcp/protocol.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 614c3f583ca0..73ec6563ab2b 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -397,12 +397,24 @@ static bool __mptcp_move_skb(struct sock *sk, struct sk_buff *skb)
return false;
}
- /* old data, keep it simple and drop the whole pkt, sender
- * will retransmit as needed, if needed.
+ /* Completely old data? */
+ if (!after64(MPTCP_SKB_CB(skb)->end_seq, msk->ack_seq)) {
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);
+ mptcp_drop(sk, skb);
+ return false;
+ }
+
+ /* Partial packet: map_seq < ack_seq < end_seq.
+ * Skip the already-acked bytes and enqueue the new data.
*/
- MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);
- mptcp_drop(sk, skb);
- return false;
+ copy_len = MPTCP_SKB_CB(skb)->end_seq - msk->ack_seq;
+ MPTCP_SKB_CB(skb)->offset += msk->ack_seq - MPTCP_SKB_CB(skb)->map_seq;
+ msk->bytes_received += copy_len;
+ WRITE_ONCE(msk->ack_seq, msk->ack_seq + copy_len);
+
+ skb_set_owner_r(skb, sk);
+ __skb_queue_tail(&sk->sk_receive_queue, skb);
+ return true;
}
static void mptcp_stop_rtx_timer(struct sock *sk)
--
2.34.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v2] mptcp: do not drop partial packets
2026-04-22 14:39 [PATCH v2] mptcp: do not drop partial packets Shardul Bankar
@ 2026-04-22 17:03 ` Matthieu Baerts
2026-04-23 12:39 ` Shardul Bankar
2026-04-24 13:20 ` Simon Horman
1 sibling, 1 reply; 4+ messages in thread
From: Matthieu Baerts @ 2026-04-22 17:03 UTC (permalink / raw)
To: Shardul Bankar, pabeni, martineau
Cc: geliang, davem, edumazet, kuba, horms, netdev, mptcp,
linux-kernel, janak, kalpan.jani, Shardul Bankar
Hi Shardul,
On 22/04/2026 16:39, Shardul Bankar wrote:
> When a packet arrives with map_seq < ack_seq < end_seq, the beginning
> of the packet has already been acknowledged but the end contains new
> data. Currently the entire packet is dropped as "old data," forcing
> the sender to retransmit.
>
> Instead, skip the already-acked bytes by adjusting the skb offset and
> enqueue only the new portion. Update bytes_received and ack_seq to
> reflect the new data consumed.
Thank you for the v2.
I didn't review it (yet), but just to let you know that there are some
rules on Netdev [1] (that usually also applied on MPTCP side), and an
important one is:
- don't repost your patches within one 24h period
Each version generates a lot of emails that are sent and need to be
triaged. With the high volume, it is then harder for us to follow, plus
a lot of shared resources are used, etc.
One last thing, because this patch is not an urgent fix, do you mind
sending new versions only the to MPTCP ML: to a restricted number of
people for the first versions, there is enough traffic on Netdev.
[1] https://docs.kernel.org/process/maintainer-netdev.html
> A previous attempt at this fix (commit 1d2ce718811a ("mptcp: do not
> drop partial packets"), reverted in commit bf39160c4218 ("Revert
Note: these two commits should not be mentioned here, they have only
been applied to the MPTCP tree, but not upstreamed. Instead, please use
lore links, e.g.
https://lore.kernel.org/c9b426a4e163aa3c4fe8b80c79f1a610f47ae7d8.1763075056.git.pabeni@redhat.com
> "mptcp: do not drop partial packets"")) also added a zero-window
> check and changed rcv_wnd_sent initialization, which caused test
> regressions. This version addresses only the partial packet handling
> without modifying receive window accounting.
>
> Fixes: ab174ad8ef76 ("mptcp: move ooo skbs into msk out of order queue.")
> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/600
> Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
Checkpatch is complaining that the author of the patch is not the same
as the one who sent the patch; You probably need to run this command to
fix it:
git commit --amend --reset-author
(when the patch is sent, `git format-patch` will add a second From: tag)
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] mptcp: do not drop partial packets
2026-04-22 17:03 ` Matthieu Baerts
@ 2026-04-23 12:39 ` Shardul Bankar
0 siblings, 0 replies; 4+ messages in thread
From: Shardul Bankar @ 2026-04-23 12:39 UTC (permalink / raw)
To: Matthieu Baerts, pabeni, martineau
Cc: geliang, davem, edumazet, kuba, horms, netdev, mptcp,
linux-kernel, janak, kalpan.jani
On Wed, 2026-04-22 at 19:03 +0200, Matthieu Baerts wrote:
> Hi Shardul,
>
> On 22/04/2026 16:39, Shardul Bankar wrote:
> >
>
> Thank you for the v2.
>
> I didn't review it (yet), but just to let you know that there are
> some
> rules on Netdev [1] (that usually also applied on MPTCP side), and an
> important one is:
>
> - don't repost your patches within one 24h period
>
> Each version generates a lot of emails that are sent and need to be
> triaged. With the high volume, it is then harder for us to follow,
> plus
> a lot of shared resources are used, etc.
>
> One last thing, because this patch is not an urgent fix, do you mind
> sending new versions only the to MPTCP ML: to a restricted number of
> people for the first versions, there is enough traffic on Netdev.
>
> [1] https://docs.kernel.org/process/maintainer-netdev.html
>
> > A previous attempt at this fix (commit 1d2ce718811a ("mptcp: do not
> > drop partial packets"), reverted in commit bf39160c4218 ("Revert
>
> Note: these two commits should not be mentioned here, they have only
> been applied to the MPTCP tree, but not upstreamed. Instead, please
> use
> lore links, e.g.
>
> https://lore.kernel.org/c9b426a4e163aa3c4fe8b80c79f1a610f47ae7d8.1763075056.git.pabeni@redhat.com
>
> > "mptcp: do not drop partial packets"")) also added a zero-window
> > check and changed rcv_wnd_sent initialization, which caused test
> > regressions. This version addresses only the partial packet
> > handling
> > without modifying receive window accounting.
> >
> > Fixes: ab174ad8ef76 ("mptcp: move ooo skbs into msk out of order
> > queue.")
> > Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/600
> > Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
>
> Checkpatch is complaining that the author of the patch is not the
> same
> as the one who sent the patch; You probably need to run this command
> to
> fix it:
>
> git commit --amend --reset-author
>
> (when the patch is sent, `git format-patch` will add a second From:
> tag)
>
> Cheers,
> Matt
Hi Matthieu,
Thanks for the pointers. I'll wait for your code review and address the
process feedback (recipient list, commit message, email mismatch) along
with any code comments together in v3.
Regards,
Shardul
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] mptcp: do not drop partial packets
2026-04-22 14:39 [PATCH v2] mptcp: do not drop partial packets Shardul Bankar
2026-04-22 17:03 ` Matthieu Baerts
@ 2026-04-24 13:20 ` Simon Horman
1 sibling, 0 replies; 4+ messages in thread
From: Simon Horman @ 2026-04-24 13:20 UTC (permalink / raw)
To: shardulsb08
Cc: 'Simon Horman', pabeni, matttbe, martineau, geliang,
davem, edumazet, kuba, netdev, mptcp, linux-kernel, janak,
kalpan.jani, shardul.b
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
mptcp: do not drop partial packets
This commit modifies the handling of out-of-order packets where
map_seq < ack_seq < end_seq. Instead of dropping the entire packet,
it skips the already-acknowledged bytes and enqueues the remainder.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/600
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index fbffd3a43fe86..4e9fba692a701 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
[ ... ]
> @@ -397,12 +397,24 @@ static bool __mptcp_move_skb(struct sock *sk, struct sk_buff *skb)
[ ... ]
> + /* Partial packet: map_seq < ack_seq < end_seq.
> + * Skip the already-acked bytes and enqueue the new data.
> + */
> + copy_len = MPTCP_SKB_CB(skb)->end_seq - msk->ack_seq;
> + MPTCP_SKB_CB(skb)->offset += msk->ack_seq - MPTCP_SKB_CB(skb)->map_seq;
> + msk->bytes_received += copy_len;
> + WRITE_ONCE(msk->ack_seq, msk->ack_seq + copy_len);
Should MPTCP_SKB_CB(skb)->map_seq also be advanced here to reflect the newly
adjusted offset?
If map_seq remains stale after skipping the already-acked bytes, does this
cause mptcp_inq_hint() to overestimate the amount of unread data?
Looking at the hint calculation, it calculates the unread bytes using
READ_ONCE(msk->ack_seq) - MPTCP_SKB_CB(skb)->map_seq for the first
enqueued SKB.
If inq_hint is artificially large, could this corrupt the ioctl(FIONREAD)
and TCP_INQ cmsg values returned to userspace?
Furthermore, could this suppress receive window auto-tuning? In
mptcp_rcv_space_adjust(), an artificially large inq_hint might cause
the calculation copied -= mptcp_inq_hint(sk) to become negative, which
would stall window growth.
> +
> + skb_set_owner_r(skb, sk);
> + __skb_queue_tail(&sk->sk_receive_queue, skb);
> + return true;
> }
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-04-24 13:21 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-22 14:39 [PATCH v2] mptcp: do not drop partial packets Shardul Bankar
2026-04-22 17:03 ` Matthieu Baerts
2026-04-23 12:39 ` Shardul Bankar
2026-04-24 13:20 ` Simon Horman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox