From: Paolo Abeni <pabeni@redhat.com>
To: Jiayuan Chen <jiayuan.chen@linux.dev>, mptcp@lists.linux.dev
Cc: stable@vger.kernel.org, Jakub Sitnicki <jakub@cloudflare.com>,
John Fastabend <john.fastabend@gmail.com>,
Eric Dumazet <edumazet@google.com>,
Kuniyuki Iwashima <kuniyu@google.com>,
Willem de Bruijn <willemb@google.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Simon Horman <horms@kernel.org>,
Matthieu Baerts <matttbe@kernel.org>,
Mat Martineau <martineau@kernel.org>,
Geliang Tang <geliang@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, Shuah Khan <shuah@kernel.org>,
Florian Westphal <fw@strlen.de>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net v3 2/3] bpf,sockmap: disallow MPTCP sockets from sockmap
Date: Tue, 28 Oct 2025 13:03:58 +0100 [thread overview]
Message-ID: <c5021188-593c-431c-bf01-6775f5b2b2ed@redhat.com> (raw)
In-Reply-To: <20251023125450.105859-3-jiayuan.chen@linux.dev>
On 10/23/25 2:54 PM, Jiayuan Chen wrote:
> MPTCP creates subflows for data transmission, and these sockets should not
> be added to sockmap because MPTCP sets specialized data_ready handlers
> that would be overridden by sockmap.
>
> Additionally, for the parent socket of MPTCP subflows (plain TCP socket),
> MPTCP sk requires specific protocol handling that conflicts with sockmap's
> operation(mptcp_prot).
>
> This patch adds proper checks to reject MPTCP subflows and their parent
> sockets from being added to sockmap, while preserving compatibility with
> reuseport functionality for listening MPTCP sockets.
It's unclear to me why that is safe. sockmap is going to change the
listener msk proto ops.
The listener could disconnect and create an egress connection, still
using the wrong ops.
I think sockmap should always be prevented for mptcp socket, or at least
a solid explanation of why such exception is safe should be included in
the commit message.
Note that the first option allows for solving the issue entirely in the
mptcp code, setting dummy/noop psock_update_sk_prot for mptcp sockets
and mptcp subflows.
/P
next prev parent reply other threads:[~2025-10-28 12:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-23 12:54 [PATCH net v3 0/3] mptcp: Fix conflicts between MPTCP and sockmap Jiayuan Chen
2025-10-23 12:54 ` [PATCH net v3 1/3] net,mptcp: fix proto fallback detection with BPF sockmap Jiayuan Chen
2025-10-23 14:10 ` Matthieu Baerts
2025-10-23 14:38 ` Jiayuan Chen
2025-10-28 11:30 ` Paolo Abeni
2025-10-28 11:47 ` Paolo Abeni
2025-11-03 12:45 ` Jiayuan Chen
2025-11-03 12:44 ` Jiayuan Chen
2025-10-23 12:54 ` [PATCH net v3 2/3] bpf,sockmap: disallow MPTCP sockets from sockmap Jiayuan Chen
2025-10-28 12:03 ` Paolo Abeni [this message]
2025-11-03 12:52 ` Jiayuan Chen
2025-10-23 12:54 ` [PATCH net v3 3/3] selftests/bpf: Add mptcp test with sockmap Jiayuan Chen
2025-10-23 14:10 ` [PATCH net v3 0/3] mptcp: Fix conflicts between MPTCP and sockmap Matthieu Baerts
2025-10-24 4:13 ` Jiayuan Chen
2025-10-28 17:26 ` Matthieu Baerts
2025-11-03 12:34 ` Jiayuan Chen
2025-11-03 15:53 ` Matthieu Baerts
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=c5021188-593c-431c-bf01-6775f5b2b2ed@redhat.com \
--to=pabeni@redhat.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=geliang@kernel.org \
--cc=haoluo@google.com \
--cc=horms@kernel.org \
--cc=jakub@cloudflare.com \
--cc=jiayuan.chen@linux.dev \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=martineau@kernel.org \
--cc=matttbe@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=stable@vger.kernel.org \
--cc=willemb@google.com \
--cc=yonghong.song@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox