Re: [PATCH mptcp-next 5/6] mptcp: trim the duplicated skb head at receive enqueue

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?

This change adds a lot of complexity to the rx path, we want to avoid it.

/P