From: Geliang Tang <geliang@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>, mptcp@lists.linux.dev
Cc: Geliang Tang <tanggeliang@kylinos.cn>
Subject: Re: [PATCH mptcp-next 5/6] mptcp: trim the duplicated skb head at receive enqueue
Date: Thu, 30 Jul 2026 09:15:11 +0800 [thread overview]
Message-ID: <4651fc61637f8be39654decec137010ffcd81991.camel@kernel.org> (raw)
In-Reply-To: <15adac30-7d7f-4637-91b7-3310f64cdb13@redhat.com>
Hi Paolo,
On Wed, 2026-07-29 at 10:08 +0200, Paolo Abeni wrote:
> On 7/27/26 1:29 PM, Geliang Tang wrote:
> > The linear readers (recvmsg, read_sock, read_done) cope with that
> > by
> > computing a per-skb offset = copied_seq - map_seq and skipping it.
> > But
> > consumers that treat the receive queue as a single contiguous byte
> > stream cannot: the TLS strparser builds an anchor whose frag_list
> > is
> > the receive-queue skbs and reads it with a plain skb_copy_bits(),
> > which
> > has no per-skb offset knowledge. A record spanning such an skb
> > boundary
> > then reads the duplicated prefix and gets corrupted.
>
> The above raises a question.
>
> AFAICS, the critical skb layout is also possible with plain TCP -
> possibly is just less likely. How does TLS deal with that? I read the
> above as the TLS stream get corrupted, which sounds suspiciously too
> fragile to me?!? Or did I miss something?
My description was inaccurate. This only occurs in the MPTCP out-of-
order scenario. It does not happen with TCP.
>
> This change adds a lot of complexity to the rx path, we want to avoid
> it.
I agree with you. This helper mptcp_trim_dup_head() does not need to be
called in __mptcp_move_skb(). It only needs to be called when
overlapping data occurs in __mptcp_ofo_queue(). This way, it won't
affect the efficiency of the rx path.
static bool __mptcp_ofo_queue(struct mptcp_sock *msk)
{
struct sock *sk = (struct sock *)msk;
struct sk_buff *skb, *tail;
u32 seq_delta, ack_seq;
bool moved = false;
struct rb_node *p;
p = rb_first(&msk->out_of_order_queue);
while (p) {
... ...
seq_delta = MPTCP_SKB_CB(skb)->end_seq - ack_seq;
tail = skb_peek_tail(&sk->sk_receive_queue);
if (!tail || !mptcp_try_coalesce(sk, tail, skb)) {
int delta = ack_seq - MPTCP_SKB_CB(skb)->map_seq;
/* trim overlapping prefix, if any */
pr_debug("uncoalesced seq=%x ack seq=%x delta=%d\n",
MPTCP_SKB_CB(skb)->map_seq, ack_seq,
delta);
if (mptcp_trim_head(skb, delta)) {
mptcp_drop(sk, skb);
continue;
}
MPTCP_SKB_CB(skb)->map_seq += delta;
__skb_queue_tail(&sk->sk_receive_queue, skb);
}
msk->bytes_received += seq_delta;
WRITE_ONCE(msk->ack_seq, msk->ack_seq + seq_delta);
moved = true;
}
return moved;
}
This helper is actually a mirror of the tcp_trim_head(). If we could
export and reuse TCP's __pskb_trim_head(), this helper would become
much simpler:
static int mptcp_trim_head(struct sk_buff *skb, int delta)
{
int eat;
if (skb_unclone_keeptruesize(skb, GFP_ATOMIC))
return -ENOMEM;
eat = min_t(int, delta, skb_headlen(skb));
if (eat) {
__skb_pull(skb, eat);
delta -= eat;
}
if (delta) {
__pskb_trim_head(skb, delta);
skb->len += skb_headlen(skb);
}
return 0;
}
Would this implementation be better? Please give me some feedback.
Thanks,
-Geliang
>
> /P
>
next prev parent reply other threads:[~2026-07-30 1:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 11:29 [PATCH mptcp-next 0/6] Reduce the differences between TCP and MPTCP for TLS usage Geliang Tang
2026-07-27 11:29 ` [PATCH mptcp-next 1/6] mptcp: drop the mptcp_ooo_try_coalesce() helper Geliang Tang
2026-07-27 11:29 ` [PATCH mptcp-next 2/6] mptcp: drop the cant_coalesce CB field Geliang Tang
2026-07-27 11:29 ` [PATCH mptcp-next 3/6] mptcp: remove CB offset field Geliang Tang
2026-07-30 1:32 ` Geliang Tang
2026-07-27 11:29 ` [PATCH mptcp-next 4/6] mptcp: sync mptcp skb cb layout with tcp one Geliang Tang
2026-07-27 11:29 ` [PATCH mptcp-next 5/6] mptcp: trim the duplicated skb head at receive enqueue Geliang Tang
2026-07-29 8:08 ` Paolo Abeni
2026-07-30 1:15 ` Geliang Tang [this message]
2026-07-30 15:00 ` Paolo Abeni
2026-07-27 11:29 ` [PATCH mptcp-next 6/6] mptcp: defer sk_data_ready to the worker Geliang Tang
2026-07-29 8:55 ` Paolo Abeni
2026-07-30 0:57 ` Geliang Tang
2026-07-30 15:18 ` Paolo Abeni
2026-07-27 12:37 ` [PATCH mptcp-next 0/6] Reduce the differences between TCP and MPTCP for TLS usage MPTCP CI
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=4651fc61637f8be39654decec137010ffcd81991.camel@kernel.org \
--to=geliang@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=pabeni@redhat.com \
--cc=tanggeliang@kylinos.cn \
/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.