linux-kernel - Re: [PATCH net v4 3/3] selftests/bpf: Add mptcp test with sockmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <cc5017b8-5802-4cf5-93b1-18b1e2bd8ae5@kernel.org>
Date: Wed, 5 Nov 2025 17:28:57 +0100
From: Matthieu Baerts <matttbe@...nel.org>
To: Jiayuan Chen <jiayuan.chen@...ux.dev>, mptcp@...ts.linux.dev
Cc: Mat Martineau <martineau@...nel.org>, Geliang Tang <geliang@...nel.org>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Simon Horman <horms@...nel.org>, Alexei Starovoitov <ast@...nel.org>,
 Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>,
 Martin KaFai Lau <martin.lau@...ux.dev>, Eduard Zingerman
 <eddyz87@...il.com>, Song Liu <song@...nel.org>,
 Yonghong Song <yonghong.song@...ux.dev>,
 John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>,
 Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>,
 Jiri Olsa <jolsa@...nel.org>, Shuah Khan <shuah@...nel.org>,
 Florian Westphal <fw@...len.de>, linux-kernel@...r.kernel.org,
 netdev@...r.kernel.org, bpf@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net v4 3/3] selftests/bpf: Add mptcp test with sockmap

On 05/11/2025 17:12, Jiayuan Chen wrote:
> November 5, 2025 at 22:40, "Matthieu Baerts" <matttbe@...nel.org mailto:matttbe@...nel.org?to=%22Matthieu%20Baerts%22%20%3Cmatttbe%40kernel.org%3E > wrote:
> 
> 
>>
>> Hi Jiayuan,
>>
>> Thank you for this new test!
>>
>> I'm not very familiar with the BPF selftests: it would be nice if
>> someone else can have a quick look.
> 
> Thanks for the review. I've seen the feedback on the other patches(1/3, 2/3) and will fix them up.

Thanks!

>> On 05/11/2025 12:36, Jiayuan Chen wrote:
>>
>>>
>>> Add test cases to verify that when MPTCP falls back to plain TCP sockets,
>>>  they can properly work with sockmap.
>>>  
>>>  Additionally, add test cases to ensure that sockmap correctly rejects
>>>  MPTCP sockets as expected.
>>>  
>>>  Signed-off-by: Jiayuan Chen <jiayuan.chen@...ux.dev>
>>>  ---
>>>  .../testing/selftests/bpf/prog_tests/mptcp.c | 150 ++++++++++++++++++
>>>  .../selftests/bpf/progs/mptcp_sockmap.c | 43 +++++
>>>  2 files changed, 193 insertions(+)
>>>  create mode 100644 tools/testing/selftests/bpf/progs/mptcp_sockmap.c
>>>  
>>>  diff --git a/tools/testing/selftests/bpf/prog_tests/mptcp.c b/tools/testing/selftests/bpf/prog_tests/mptcp.c
>>>  index f8eb7f9d4fd2..56c556f603cc 100644
>>>  --- a/tools/testing/selftests/bpf/prog_tests/mptcp.c
>>>  +++ b/tools/testing/selftests/bpf/prog_tests/mptcp.c
>>>  @@ -6,11 +6,14 @@
>>>  #include <netinet/in.h>
>>>  #include <test_progs.h>
>>>  #include <unistd.h>
>>>  +#include <error.h>
>>>
>> Do you use this new include?
> 
> "EOPNOTSUPP" I used was defined in error.h.

Ah OK. I usually only include 'error.h' to use 'error()'.
Is it not 'errno.h' (or 'linux/errno.h') you want instead?

I'm just surprised it is not already included but another one above. But
OK if it is not.

(...)

>>> + return;
>>>  +
>>>  + skel->bss->trace_port = ntohs(get_socket_local_port(listen_fd));
>>>  + skel->bss->sk_index = 0;
>>>  + /* create client with MPTCP enabled */
>>>  + client_fd1 = connect_to_fd(listen_fd, 0);
>>>  + if (!ASSERT_OK_FD(client_fd1, "connect_to_fd client_fd1"))
>>>  + goto end;
>>>  +
>>>  + /* bpf_sock_map_update() called from sockops should reject MPTCP sk */
>>>  + if (!ASSERT_EQ(skel->bss->helper_ret, -EOPNOTSUPP, "should reject"))
>>>  + goto end;
>>>
>> So here, the client is connected, but sockmap doesn't operate on it,
>> right? So most likely, the connection is stalled until the userspace
>> realises that and takes an action?
>>
> 
> It depends. Sockmap usually runs as a bypass. The user app (like Nginx)
> has its own native forwarding logic, and sockmap just kicks in to accelerate
> it. So in known cases, turning off sockmap falls back to the native logic.
> But if there's no native logic, the connection just stalls.

Good to know, thanks!

So MPTCP request might still be handled by the "native logic" if any?

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.