All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Geliang Tang" <geliang@kernel.org>, mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next v27 6/8] mptcp: remove CB offset field
Date: Sat, 14 Nov 2026 14:29:17 +0000	[thread overview]
Message-ID: <sashiko-outbox-214634@kernel.org> (raw)
In-Reply-To: <879f04c4a89da0b3e8bcc7fd484744be5851f17e.1794663678.git.tanggeliang@kylinos.cn>

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [High] mptcp: raw map_seq used instead of mptcp_dsn() in
  mptcp_data_queue_ofo()
- [Medium] mptcp: raw map_seq and end_seq used in
  mptcp_prune_ofo_queue() and tracepoint
--

commit 9093e378164791c8e9a9ecffc602703ba0b1790e
Author: Paolo Abeni <pabeni@redhat.com>

mptcp: remove CB offset field

This commit removes the offset field from struct mptcp_skb_cb, tracking
consumed bytes via msk->copied_seq and encoding any subflow skb offset into
MPTCP_SKB_CB(skb)->map_seq alongside the mptcp_dsn() and mptcp_end_dsn()
helpers.

> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index 41fc2429d2fed..f4ab3bdd368f2 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c

[ ... ]

> @@ -362,8 +363,8 @@ static void mptcp_data_queue_ofo(struct mptcp_sock *msk, struct sk_buff *skb)
>  			p = &parent->rb_left;
>  			continue;
>  		}
> -		if (before64(seq, MPTCP_SKB_CB(skb1)->end_seq)) {
> -			if (!after64(end_seq, MPTCP_SKB_CB(skb1)->end_seq)) {
> +		if (before64(seq, mptcp_end_dsn(skb1))) {
> +			if (!after64(end_seq, mptcp_end_dsn(skb1))) {
>  				/* All the bits are present. Drop. */
>  				mptcp_drop(sk, skb);
>  				MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);

[Severity: High]
Should the RB-tree traversal in mptcp_data_queue_ofo() compare seq against
mptcp_dsn(skb1) instead of MPTCP_SKB_CB(skb1)->map_seq?

net/mptcp/protocol.c:mptcp_data_queue_ofo() {
    ...
	while (*p) {
		parent = *p;
		skb1 = rb_to_skb(parent);
		if (before64(seq, MPTCP_SKB_CB(skb1)->map_seq)) {
			p = &parent->rb_left;
			continue;
		}
		if (before64(seq, mptcp_end_dsn(skb1))) {
			if (!after64(end_seq, mptcp_end_dsn(skb1))) {
				/* All the bits are present. Drop. */
				mptcp_drop(sk, skb);
				MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);
				return;
			}
			if (after64(seq, MPTCP_SKB_CB(skb1)->map_seq)) {
    ...
}

When mptcp_init_skb() initializes an skb with a non-zero subflow offset,
MPTCP_SKB_CB(skb1)->map_seq is set to mptcp_dsn(skb1) - offset.  If that skb
is queued in msk->out_of_order_queue and a subsequent out-of-order segment
arrives with seq in [mptcp_dsn(skb1) - offset, mptcp_dsn(skb1)), the
before64(seq, MPTCP_SKB_CB(skb1)->map_seq) check is false instead of moving to
rb_left.  Any segment in that range with end_seq <= mptcp_end_dsn(skb1) (such
as the segment immediately preceding skb1) is then dropped as duplicate data,
or if end_seq > mptcp_end_dsn(skb1) it is inserted into the right subtree of
skb1 despite having a smaller DSN, stalling the receive queue when
__mptcp_ofo_queue() later stops at mptcp_dsn(skb1) > msk->ack_seq.

[ ... ]

> @@ -425,9 +426,10 @@ static void mptcp_init_skb(struct sock *ssk, struct sk_buff *skb, int offset,
>  	 * mptcp_subflow_get_mapped_dsn() is based on the current tp->copied_seq
>  	 * value
>  	 */
> -	MPTCP_SKB_CB(skb)->map_seq = mptcp_subflow_get_mapped_dsn(subflow);
> +	MPTCP_SKB_CB(skb)->map_seq = mptcp_subflow_get_mapped_dsn(subflow) -
> +				     offset;
>  	MPTCP_SKB_CB(skb)->end_seq = MPTCP_SKB_CB(skb)->map_seq + copy_len;
> -	MPTCP_SKB_CB(skb)->offset = offset;
> +	MPTCP_SKB_CB(skb)->flags = offset ? MPTCP_SKB_CB_F_OFFSET : 0;
>  	MPTCP_SKB_CB(skb)->has_rxtstamp = has_rxtstamp;

[Severity: Medium]
Now that map_seq and end_seq are shifted down by offset, should
mptcp_prune_ofo_queue() and trace_mptcp_rcvbuf_grow() also use mptcp_dsn() and
mptcp_end_dsn()?

net/mptcp/protocol.c:mptcp_prune_ofo_queue() {
    ...
		/* Stop pruning if the incoming skb would land in OoO tail. */
		if (after64(MPTCP_SKB_CB(in_skb)->map_seq,
			    MPTCP_SKB_CB(skb)->map_seq))
			break;
    ...
}

When either in_skb or the tail skb in msk->out_of_order_queue has a non-zero
offset, comparing raw map_seq values can stop pruning early (causing
__mptcp_move_skb() or mptcp_data_queue_ofo() to drop an earlier segment under
memory pressure) or prune out-of-order segments whose actual DSN precedes
in_skb.  Similarly, the mptcp_rcvbuf_grow tracepoint in
include/trace/events/mptcp.h still computes ooo_space from
MPTCP_SKB_CB(msk->ooo_last_skb)->end_seq - msk->ack_seq instead of
mptcp_end_dsn(msk->ooo_last_skb) - msk->ack_seq.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1794663678.git.tanggeliang@kylinos.cn?part=6

  reply	other threads:[~2026-11-14 14:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-14 14:00 [PATCH mptcp-next v27 0/8] Reduce the differences between TCP and MPTCP for TLS usage Geliang Tang
2026-11-14 14:00 ` [PATCH mptcp-next v27 1/8] mptcp: fix TFO SIOCINQ overflow in mptcp_inq_hint Geliang Tang
2026-11-14 14:00 ` [PATCH mptcp-next v27 2/8] selftests: mptcp: connect: check TFO SIOCINQ overflow Geliang Tang
2026-11-14 14:00 ` [PATCH mptcp-next v27 3/8] mptcp: fix fallback dummy mapping anchor Geliang Tang
2026-11-14 14:01 ` [PATCH mptcp-next v27 4/8] mptcp: drop the mptcp_ooo_try_coalesce() helper Geliang Tang
2026-11-14 14:01 ` [PATCH mptcp-next v27 5/8] mptcp: drop the cant_coalesce CB field Geliang Tang
2026-11-14 14:01 ` [PATCH mptcp-next v27 6/8] mptcp: remove CB offset field Geliang Tang
2026-11-14 14:29   ` sashiko-bot [this message]
2026-11-14 14:01 ` [PATCH mptcp-next v27 7/8] mptcp: sync mptcp skb cb layout with tcp one Geliang Tang
2026-11-14 14:41   ` sashiko-bot
2026-11-14 14:01 ` [PATCH mptcp-next v27 8/8] mptcp: defer read_sock cleanup to mptcp_worker Geliang Tang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-214634@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=geliang@kernel.org \
    --cc=mptcp@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.