[v4] mptcp: Fix conflicts between MPTCP and sockmap

[PATCH net v4 3/3] selftests/bpf: Add mptcp test with sockmap

Posted by Jiayuan Chen 3 weeks, 1 day ago

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@linux.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>
 #include "cgroup_helpers.h"
 #include "network_helpers.h"
+#include "socket_helpers.h"
 #include "mptcp_sock.skel.h"
 #include "mptcpify.skel.h"
 #include "mptcp_subflow.skel.h"
+#include "mptcp_sockmap.skel.h"
 
 #define NS_TEST "mptcp_ns"
 #define ADDR_1	"10.0.1.1"
@@ -436,6 +439,151 @@ static void test_subflow(void)
 	close(cgroup_fd);
 }
 
+/* Test sockmap on MPTCP server handling non-mp-capable clients. */
+static void test_sockmap_with_mptcp_fallback(struct mptcp_sockmap *skel)
+{
+	int listen_fd = -1, client_fd1 = -1, client_fd2 = -1;
+	int server_fd1 = -1, server_fd2 = -1, sent, recvd;
+	char snd[9] = "123456789";
+	char rcv[10];
+
+	/* start server with MPTCP enabled */
+	listen_fd = start_mptcp_server(AF_INET, NULL, 0, 0);
+	if (!ASSERT_OK_FD(listen_fd, "redirect:start_mptcp_server"))
+		return;
+
+	skel->bss->trace_port = ntohs(get_socket_local_port(listen_fd));
+	skel->bss->sk_index = 0;
+	/* create client without MPTCP enabled */
+	client_fd1 = connect_to_fd_opts(listen_fd, NULL);
+	if (!ASSERT_OK_FD(client_fd1, "redirect:connect_to_fd"))
+		goto end;
+
+	server_fd1 = xaccept_nonblock(listen_fd, NULL, NULL);
+	skel->bss->sk_index = 1;
+	client_fd2 = connect_to_fd_opts(listen_fd, NULL);
+	if (!ASSERT_OK_FD(client_fd2, "redirect:connect_to_fd"))
+		goto end;
+
+	server_fd2 = xaccept_nonblock(listen_fd, NULL, NULL);
+	/* test normal redirect behavior: data sent by client_fd1 can be
+	 * received by client_fd2
+	 */
+	skel->bss->redirect_idx = 1;
+	sent = xsend(client_fd1, snd, sizeof(snd), 0);
+	if (!ASSERT_EQ(sent, sizeof(snd), "redirect:xsend(client_fd1)"))
+		goto end;
+
+	/* try to recv more bytes to avoid truncation check */
+	recvd = recv_timeout(client_fd2, rcv, sizeof(rcv), MSG_DONTWAIT, 2);
+	if (!ASSERT_EQ(recvd, sizeof(snd), "redirect:recv(client_fd2)"))
+		goto end;
+
+end:
+	if (client_fd1 > 1)
+		close(client_fd1);
+	if (client_fd2 > 1)
+		close(client_fd2);
+	if (server_fd1 > 0)
+		close(server_fd1);
+	if (server_fd2 > 0)
+		close(server_fd2);
+	close(listen_fd);
+}
+
+/* Test sockmap rejection of MPTCP sockets - both server and client sides. */
+static void test_sockmap_reject_mptcp(struct mptcp_sockmap *skel)
+{
+	int client_fd1 = -1, client_fd2 = -1;
+	int listen_fd = -1, server_fd = -1;
+	int err, zero = 0;
+
+	/* start server with MPTCP enabled */
+	listen_fd = start_mptcp_server(AF_INET, NULL, 0, 0);
+	if (!ASSERT_OK_FD(listen_fd, "start_mptcp_server"))
+		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;
+
+	/* set trace_port = -1 to stop sockops */
+	skel->bss->trace_port = -1;
+	client_fd2 = connect_to_fd(listen_fd, 0);
+	if (!ASSERT_OK_FD(client_fd2, "connect_to_fd client_fd2"))
+		goto end;
+
+	server_fd = xaccept_nonblock(listen_fd, NULL, NULL);
+	err = bpf_map_update_elem(bpf_map__fd(skel->maps.sock_map),
+				  &zero, &server_fd, BPF_NOEXIST);
+	if (!ASSERT_EQ(err, -EOPNOTSUPP, "server should be disallowed"))
+		goto end;
+
+	/* MPTCP client should also be disallowed */
+	err = bpf_map_update_elem(bpf_map__fd(skel->maps.sock_map),
+				  &zero, &client_fd1, BPF_NOEXIST);
+	if (!ASSERT_EQ(err, -EOPNOTSUPP, "client should be disallowed"))
+		goto end;
+end:
+	if (client_fd1 > 0)
+		close(client_fd1);
+	if (client_fd2 > 0)
+		close(client_fd2);
+	if (server_fd > 0)
+		close(server_fd);
+	close(listen_fd);
+}
+
+static void test_mptcp_sockmap(void)
+{
+	struct mptcp_sockmap *skel;
+	struct netns_obj *netns;
+	int cgroup_fd, err;
+
+	cgroup_fd = test__join_cgroup("/mptcp_sockmap");
+	if (!ASSERT_OK_FD(cgroup_fd, "join_cgroup: mptcp_sockmap"))
+		return;
+
+	skel = mptcp_sockmap__open_and_load();
+	if (!ASSERT_OK_PTR(skel, "skel_open_load: mptcp_sockmap"))
+		goto close_cgroup;
+
+	skel->links.mptcp_sockmap_inject =
+		bpf_program__attach_cgroup(skel->progs.mptcp_sockmap_inject, cgroup_fd);
+	if (!ASSERT_OK_PTR(skel->links.mptcp_sockmap_inject, "attach sockmap"))
+		goto skel_destroy;
+
+	err = bpf_prog_attach(bpf_program__fd(skel->progs.mptcp_sockmap_redirect),
+			      bpf_map__fd(skel->maps.sock_map),
+			      BPF_SK_SKB_STREAM_VERDICT, 0);
+	if (!ASSERT_OK(err, "bpf_prog_attach stream verdict"))
+		goto skel_destroy;
+
+	netns = netns_new(NS_TEST, true);
+	if (!ASSERT_OK_PTR(netns, "netns_new: mptcp_sockmap"))
+		goto skel_destroy;
+
+	if (endpoint_init("subflow") < 0)
+		goto close_netns;
+
+	test_sockmap_with_mptcp_fallback(skel);
+	test_sockmap_reject_mptcp(skel);
+
+close_netns:
+	netns_free(netns);
+skel_destroy:
+	mptcp_sockmap__destroy(skel);
+close_cgroup:
+	close(cgroup_fd);
+}
+
 void test_mptcp(void)
 {
 	if (test__start_subtest("base"))
@@ -444,4 +592,6 @@ void test_mptcp(void)
 		test_mptcpify();
 	if (test__start_subtest("subflow"))
 		test_subflow();
+	if (test__start_subtest("sockmap"))
+		test_mptcp_sockmap();
 }
diff --git a/tools/testing/selftests/bpf/progs/mptcp_sockmap.c b/tools/testing/selftests/bpf/progs/mptcp_sockmap.c
new file mode 100644
index 000000000000..d4eef0cbadb9
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/mptcp_sockmap.c
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include "bpf_tracing_net.h"
+
+char _license[] SEC("license") = "GPL";
+
+int sk_index;
+int redirect_idx;
+int trace_port;
+int helper_ret;
+struct {
+	__uint(type, BPF_MAP_TYPE_SOCKMAP);
+	__uint(key_size, sizeof(__u32));
+	__uint(value_size, sizeof(__u32));
+	__uint(max_entries, 100);
+} sock_map SEC(".maps");
+
+SEC("sockops")
+int mptcp_sockmap_inject(struct bpf_sock_ops *skops)
+{
+	struct bpf_sock *sk;
+
+	/* only accept specified connection */
+	if (skops->local_port != trace_port ||
+	    skops->op != BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB)
+		return 1;
+
+	sk = skops->sk;
+	if (!sk)
+		return 1;
+
+	/* update sk handler */
+	helper_ret = bpf_sock_map_update(skops, &sock_map, &sk_index, BPF_NOEXIST);
+
+	return 1;
+}
+
+SEC("sk_skb/stream_verdict")
+int mptcp_sockmap_redirect(struct __sk_buff *skb)
+{
+	/* redirect skb to the sk under sock_map[redirect_idx] */
+	return bpf_sk_redirect_map(skb, &sock_map, redirect_idx, 0);
+}
-- 
2.43.0

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

Posted by Matthieu Baerts 3 weeks ago

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.

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@linux.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?

>  #include "cgroup_helpers.h"
>  #include "network_helpers.h"
> +#include "socket_helpers.h"
>  #include "mptcp_sock.skel.h"
>  #include "mptcpify.skel.h"
>  #include "mptcp_subflow.skel.h"
> +#include "mptcp_sockmap.skel.h"
>  
>  #define NS_TEST "mptcp_ns"
>  #define ADDR_1	"10.0.1.1"
> @@ -436,6 +439,151 @@ static void test_subflow(void)
>  	close(cgroup_fd);
>  }
>  
> +/* Test sockmap on MPTCP server handling non-mp-capable clients. */
> +static void test_sockmap_with_mptcp_fallback(struct mptcp_sockmap *skel)
> +{
> +	int listen_fd = -1, client_fd1 = -1, client_fd2 = -1;
> +	int server_fd1 = -1, server_fd2 = -1, sent, recvd;
> +	char snd[9] = "123456789";
> +	char rcv[10];
> +
> +	/* start server with MPTCP enabled */
> +	listen_fd = start_mptcp_server(AF_INET, NULL, 0, 0);
> +	if (!ASSERT_OK_FD(listen_fd, "redirect:start_mptcp_server"))
> +		return;
> +
> +	skel->bss->trace_port = ntohs(get_socket_local_port(listen_fd));
> +	skel->bss->sk_index = 0;
> +	/* create client without MPTCP enabled */
> +	client_fd1 = connect_to_fd_opts(listen_fd, NULL);
> +	if (!ASSERT_OK_FD(client_fd1, "redirect:connect_to_fd"))
> +		goto end;
> +
> +	server_fd1 = xaccept_nonblock(listen_fd, NULL, NULL);
> +	skel->bss->sk_index = 1;
> +	client_fd2 = connect_to_fd_opts(listen_fd, NULL);
> +	if (!ASSERT_OK_FD(client_fd2, "redirect:connect_to_fd"))
> +		goto end;
> +
> +	server_fd2 = xaccept_nonblock(listen_fd, NULL, NULL);
> +	/* test normal redirect behavior: data sent by client_fd1 can be
> +	 * received by client_fd2
> +	 */
> +	skel->bss->redirect_idx = 1;
> +	sent = xsend(client_fd1, snd, sizeof(snd), 0);
> +	if (!ASSERT_EQ(sent, sizeof(snd), "redirect:xsend(client_fd1)"))
> +		goto end;
> +
> +	/* try to recv more bytes to avoid truncation check */
> +	recvd = recv_timeout(client_fd2, rcv, sizeof(rcv), MSG_DONTWAIT, 2);
> +	if (!ASSERT_EQ(recvd, sizeof(snd), "redirect:recv(client_fd2)"))
> +		goto end;
> +
> +end:
> +	if (client_fd1 > 1)
> +		close(client_fd1);
> +	if (client_fd2 > 1)
> +		close(client_fd2);
> +	if (server_fd1 > 0)
> +		close(server_fd1);
> +	if (server_fd2 > 0)
> +		close(server_fd2);

Why do you check if it is above 0 or 1? Should you not always check if
it is >= 0 for each fd?


> +	close(listen_fd);
> +}
> +
> +/* Test sockmap rejection of MPTCP sockets - both server and client sides. */
> +static void test_sockmap_reject_mptcp(struct mptcp_sockmap *skel)
> +{
> +	int client_fd1 = -1, client_fd2 = -1;
> +	int listen_fd = -1, server_fd = -1;
> +	int err, zero = 0;
> +
> +	/* start server with MPTCP enabled */
> +	listen_fd = start_mptcp_server(AF_INET, NULL, 0, 0);
> +	if (!ASSERT_OK_FD(listen_fd, "start_mptcp_server"))

In test_sockmap_with_mptcp_fallback(), you prefixed each error with
'redirect:'. Should you also have a different prefix here? 'sockmap-fb:'
vs 'sockmap-mptcp:' eventually?

> +		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?

> +	/* set trace_port = -1 to stop sockops */
> +	skel->bss->trace_port = -1;

What do you want to demonstrate from here? That without the sockmap
injection, there are no new entries added? Is it worth checking that here?

> +	client_fd2 = connect_to_fd(listen_fd, 0);
> +	if (!ASSERT_OK_FD(client_fd2, "connect_to_fd client_fd2"))
> +		goto end;
> +
> +	server_fd = xaccept_nonblock(listen_fd, NULL, NULL);
> +	err = bpf_map_update_elem(bpf_map__fd(skel->maps.sock_map),
> +				  &zero, &server_fd, BPF_NOEXIST);
> +	if (!ASSERT_EQ(err, -EOPNOTSUPP, "server should be disallowed"))
> +		goto end;
> +
> +	/* MPTCP client should also be disallowed */
> +	err = bpf_map_update_elem(bpf_map__fd(skel->maps.sock_map),
> +				  &zero, &client_fd1, BPF_NOEXIST);
> +	if (!ASSERT_EQ(err, -EOPNOTSUPP, "client should be disallowed"))
> +		goto end;
> +end:
> +	if (client_fd1 > 0)
> +		close(client_fd1);
> +	if (client_fd2 > 0)
> +		close(client_fd2);
> +	if (server_fd > 0)
> +		close(server_fd);

Same here: should it not be "*fd >= 0"?

> +	close(listen_fd);
> +}

(...)

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

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

Posted by Jiayuan Chen 3 weeks ago

November 5, 2025 at 22:40, "Matthieu Baerts" <matttbe@kernel.org mailto:matttbe@kernel.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.


> 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@linux.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.

> > 
> >  +
> >  +end:
> >  + if (client_fd1 > 1)
> >  + close(client_fd1);
> >  + if (client_fd2 > 1)
> >  + close(client_fd2);
> >  + if (server_fd1 > 0)
> >  + close(server_fd1);
> >  + if (server_fd2 > 0)
> >  + close(server_fd2);
> > 
> Why do you check if it is above 0 or 1? Should you not always check if
> it is >= 0 for each fd?

My bad, ">=0" is correct.

> > 
> > + close(listen_fd);
> >  +}
> >  +
> >  +/* Test sockmap rejection of MPTCP sockets - both server and client sides. */
> >  +static void test_sockmap_reject_mptcp(struct mptcp_sockmap *skel)
> >  +{
> >  + int client_fd1 = -1, client_fd2 = -1;
> >  + int listen_fd = -1, server_fd = -1;
> >  + int err, zero = 0;
> >  +
> >  + /* start server with MPTCP enabled */
> >  + listen_fd = start_mptcp_server(AF_INET, NULL, 0, 0);
> >  + if (!ASSERT_OK_FD(listen_fd, "start_mptcp_server"))
> > 
> In test_sockmap_with_mptcp_fallback(), you prefixed each error with
> 'redirect:'. Should you also have a different prefix here? 'sockmap-fb:'
> vs 'sockmap-mptcp:' eventually?

I will do it.

> > 
> > + 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.


> > 
> > + /* set trace_port = -1 to stop sockops */
> >  + skel->bss->trace_port = -1;
> > 
> What do you want to demonstrate from here? That without the sockmap
> injection, there are no new entries added? Is it worth checking that here?

That's redundant. I'll drop it.


[...]
> >  + if (client_fd1 > 0)
> >  + close(client_fd1);
> >  + if (client_fd2 > 0)
> >  + close(client_fd2);
> >  + if (server_fd > 0)
> >  + close(server_fd);
> > 
> Same here: should it not be "*fd >= 0"?

I will fix it.

Thanks.

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

Posted by Matthieu Baerts 3 weeks ago

On 05/11/2025 17:12, Jiayuan Chen wrote:
> November 5, 2025 at 22:40, "Matthieu Baerts" <matttbe@kernel.org mailto:matttbe@kernel.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@linux.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.

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

Posted by Jiayuan Chen 3 weeks ago

November 6, 2025 at 24:28, "Matthieu Baerts" <matttbe@kernel.org mailto:matttbe@kernel.org?to=%22Matthieu%20Baerts%22%20%3Cmatttbe%40kernel.org%3E > wrote:


> 
> On 05/11/2025 17:12, Jiayuan Chen wrote:
> 
> > 
> > November 5, 2025 at 22:40, "Matthieu Baerts" <matttbe@kernel.org mailto:matttbe@kernel.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@linux.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.


Okay, I'll look into it and see if I can get rid of the error.h header.

> > 
> > > 
> > > 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?
> 

Yes. If native logic exists, simply blocking the mixing of MPTCP and sockmap
should mostly keep the user's app working.

Thanks.

[PATCH net v4 1/3] mptcp: disallow MPTCP subflows from sockmap
[PATCH net v4 2/3] net,mptcp: fix proto fallback detection with BPF
[PATCH net v4 3/3] selftests/bpf: Add mptcp test with sockmap