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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <44dc1c4ae2304201a92d348030460a6eb8d4a282@linux.dev>
Date: Thu, 06 Nov 2025 01:46:05 +0000
From: "Jiayuan Chen" <jiayuan.chen@...ux.dev>
To: "Matthieu Baerts" <matttbe@...nel.org>, 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

November 6, 2025 at 24:28, "Matthieu Baerts" <matttbe@...nel.org mailto:matttbe@...nel.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@...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.


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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ