From: Gang Yan <yangang@kylinos.cn>

Hi, Matt, Geliang, Paolo

Patch 3-4 have been reviewed by Paolo before, and ready for merge
[1][2].

Changelog:
v3:
  - Patch 2 keeps the mptcp_setsockopt_all_sf as Geliang suggested.
v2:
  - Patches 1 and 2 are new in this series; they address TCP_MAXSEG
    handling in the bpf_setsockopt() path.
  - Patch 4 adds an early return to fix msk->sk_rcvlowat being
    unexpectedly modified, an issue seen in v1.
  - Patch 5 makes the hook safe for the non-tcp master socket: it guards
    bpf_sock_ops_cb_flags_set() with sk_is_tcp() to prevent out-of-bounds
    heap reads/writes through tcp_sk(sk)->bpf_sock_ops_cb_flags, and does
    not set is_locked_tcp_sock for the msk (unlike tcp_call_bpf()). That
    flag authorizes the verifier's direct tcp_sock-offset field accesses;
    since the msk is not a tcp_sock, leaving it at the default 0 is safe.

v1:
  Link: https://patchwork.kernel.org/project/mptcp/cover/20260713095735.1222033-1-gang.yan@linux.dev/

[1] https://patchwork.kernel.org/project/mptcp/patch/20260522-sockopt_lock-v5-2-108629a46e98@kylinos.cn/
[2] https://patchwork.kernel.org/project/mptcp/patch/20260522-sockopt_lock-v5-4-108629a46e98@kylinos.cn/

Gang Yan (7):
  mptcp: drop unused @max arg of __mptcp_setsockopt_set_val
  mptcp: take TCP_MAXSEG handling into __mptcp_setsockopt_set_val
  mptcp: use sockopt_lock/release_sock in sockopt
  mptcp: reject sockopt requiring ssks' lock in BPF context
  mptcp: enable bpf_setsockopt on the master socket
  mptcp: add TCP_CONNECT_CB sock_ops hook
  selftests: bpf: verify mptcp bpf_setsockopt from TCP_CONNECT_CB

 include/net/mptcp.h                           |   9 ++
 net/core/filter.c                             |  10 ++
 net/ipv4/tcp.c                                |   1 +
 net/mptcp/protocol.c                          |   6 +
 net/mptcp/protocol.h                          |  29 ++++
 net/mptcp/sockopt.c                           | 127 +++++++++++-------
 .../testing/selftests/bpf/prog_tests/mptcp.c  |  61 +++++++++
 .../selftests/bpf/progs/mptcp_setsockopt.c    |  32 +++++
 8 files changed, 223 insertions(+), 52 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/progs/mptcp_setsockopt.c

-- 
2.43.0

Hi Gang,

On Mon, 2026-07-27 at 10:28 +0800, Gang Yan wrote:
> From: Gang Yan <yangang@kylinos.cn>
> 
> Hi, Matt, Geliang, Paolo
> 
> Patch 3-4 have been reviewed by Paolo before, and ready for merge
> [1][2].

Do not put unrelated code into a single series. This series is for
adding bpf_setsockopt support; other patches do not belong here.

> 
> Changelog:
> v3:
>   - Patch 2 keeps the mptcp_setsockopt_all_sf as Geliang suggested.

I recommend that you hold off on sending this patch for now: "Let's
wait until IPV6_TCLASS is merged before posting this patch." Rather
than keeping an unused mptcp_setsockopt_all_sf.

Do not send code that has not passed compilation to the mailing list.

> v2:
>   - Patches 1 and 2 are new in this series; they address TCP_MAXSEG
>     handling in the bpf_setsockopt() path.
>   - Patch 4 adds an early return to fix msk->sk_rcvlowat being
>     unexpectedly modified, an issue seen in v1.
>   - Patch 5 makes the hook safe for the non-tcp master socket: it
> guards
>     bpf_sock_ops_cb_flags_set() with sk_is_tcp() to prevent out-of-
> bounds
>     heap reads/writes through tcp_sk(sk)->bpf_sock_ops_cb_flags, and
> does
>     not set is_locked_tcp_sock for the msk (unlike tcp_call_bpf()).
> That
>     flag authorizes the verifier's direct tcp_sock-offset field
> accesses;
>     since the msk is not a tcp_sock, leaving it at the default 0 is
> safe.
> 
> v1:
>   Link:
> https://patchwork.kernel.org/project/mptcp/cover/20260713095735.1222033-1-gang.yan@linux.dev/
> 
> [1]
> https://patchwork.kernel.org/project/mptcp/patch/20260522-sockopt_lock-v5-2-108629a46e98@kylinos.cn/
> [2]
> https://patchwork.kernel.org/project/mptcp/patch/20260522-sockopt_lock-v5-4-108629a46e98@kylinos.cn/
> 
> Gang Yan (7):
>   mptcp: drop unused @max arg of __mptcp_setsockopt_set_val
>   mptcp: take TCP_MAXSEG handling into __mptcp_setsockopt_set_val
>   mptcp: use sockopt_lock/release_sock in sockopt
>   mptcp: reject sockopt requiring ssks' lock in BPF context
>   mptcp: enable bpf_setsockopt on the master socket
>   mptcp: add TCP_CONNECT_CB sock_ops hook
>   selftests: bpf: verify mptcp bpf_setsockopt from TCP_CONNECT_CB
> 
>  include/net/mptcp.h                           |   9 ++
>  net/core/filter.c                             |  10 ++
>  net/ipv4/tcp.c                                |   1 +
>  net/mptcp/protocol.c                          |   6 +
>  net/mptcp/protocol.h                          |  29 ++++
>  net/mptcp/sockopt.c                           | 127 +++++++++++-----
> --
>  .../testing/selftests/bpf/prog_tests/mptcp.c  |  61 +++++++++
>  .../selftests/bpf/progs/mptcp_setsockopt.c    |  32 +++++
>  8 files changed, 223 insertions(+), 52 deletions(-)
>  create mode 100644
> tools/testing/selftests/bpf/progs/mptcp_setsockopt.c

July 27, 2026 at 2:04 PM, "Geliang Tang" <geliang@kernel.org mailto:geliang@kernel.org?to=%22Geliang%20Tang%22%20%3Cgeliang%40kernel.org%3E > wrote:


> 
> Hi Gang,
> 
> On Mon, 2026-07-27 at 10:28 +0800, Gang Yan wrote:
> 
> > 
> > From: Gang Yan <yangang@kylinos.cn>
> >  
> >  Hi, Matt, Geliang, Paolo
> >  
> >  Patch 3-4 have been reviewed by Paolo before, and ready for merge
> >  [1][2].
> > 
> Do not put unrelated code into a single series. This series is for
> adding bpf_setsockopt support; other patches do not belong here.
> 
> > 
> > Changelog:
> >  v3:
> >    - Patch 2 keeps the mptcp_setsockopt_all_sf as Geliang suggested.
> > 
> I recommend that you hold off on sending this patch for now: "Let's
> wait until IPV6_TCLASS is merged before posting this patch." Rather
> than keeping an unused mptcp_setsockopt_all_sf.
> 
> Do not send code that has not passed compilation to the mailing list.
>

Hi Geliang
 
I sincerely apologize for the noise. I'll drop this patch and wait for the IPV6_TCLASS merge.

Thanks
Gang
> > 
> > v2:
> >    - Patches 1 and 2 are new in this series; they address TCP_MAXSEG
> >      handling in the bpf_setsockopt() path.
> >    - Patch 4 adds an early return to fix msk->sk_rcvlowat being
> >      unexpectedly modified, an issue seen in v1.
> >    - Patch 5 makes the hook safe for the non-tcp master socket: it
> >  guards
> >      bpf_sock_ops_cb_flags_set() with sk_is_tcp() to prevent out-of-
> >  bounds
> >      heap reads/writes through tcp_sk(sk)->bpf_sock_ops_cb_flags, and
> >  does
> >      not set is_locked_tcp_sock for the msk (unlike tcp_call_bpf()).
> >  That
> >      flag authorizes the verifier's direct tcp_sock-offset field
> >  accesses;
> >      since the msk is not a tcp_sock, leaving it at the default 0 is
> >  safe.
> >  
> >  v1:
> >    Link:
> >  https://patchwork.kernel.org/project/mptcp/cover/20260713095735.1222033-1-gang.yan@linux.dev/
> >  
> >  [1]
> >  https://patchwork.kernel.org/project/mptcp/patch/20260522-sockopt_lock-v5-2-108629a46e98@kylinos.cn/
> >  [2]
> >  https://patchwork.kernel.org/project/mptcp/patch/20260522-sockopt_lock-v5-4-108629a46e98@kylinos.cn/
> >  
> >  Gang Yan (7):
> >    mptcp: drop unused @max arg of __mptcp_setsockopt_set_val
> >    mptcp: take TCP_MAXSEG handling into __mptcp_setsockopt_set_val
> >    mptcp: use sockopt_lock/release_sock in sockopt
> >    mptcp: reject sockopt requiring ssks' lock in BPF context
> >    mptcp: enable bpf_setsockopt on the master socket
> >    mptcp: add TCP_CONNECT_CB sock_ops hook
> >    selftests: bpf: verify mptcp bpf_setsockopt from TCP_CONNECT_CB
> >  
> >   include/net/mptcp.h                           |   9 ++
> >   net/core/filter.c                             |  10 ++
> >   net/ipv4/tcp.c                                |   1 +
> >   net/mptcp/protocol.c                          |   6 +
> >   net/mptcp/protocol.h                          |  29 ++++
> >   net/mptcp/sockopt.c                           | 127 +++++++++++-----
> >  --
> >   .../testing/selftests/bpf/prog_tests/mptcp.c  |  61 +++++++++
> >   .../selftests/bpf/progs/mptcp_setsockopt.c    |  32 +++++
> >   8 files changed, 223 insertions(+), 52 deletions(-)
> >   create mode 100644
> >  tools/testing/selftests/bpf/progs/mptcp_setsockopt.c
> >
>

Hi Gang,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal (except selftest_mptcp_join): Script error! ❓
- KVM Validation: normal (only selftest_mptcp_join): Script error! ❓
- KVM Validation: debug (except selftest_mptcp_join): Script error! ❓
- KVM Validation: debug (only selftest_mptcp_join): Script error! ❓
- KVM Validation: btf-normal (only bpftest_all): Script error! ❓
- KVM Validation: btf-debug (only bpftest_all): Script error! ❓
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/30233020793

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/acb09ec8b8b1
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1134827


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)

Hi Gang,

Thank you for your modifications, that's great!

But sadly, our CI spotted some issues with it when trying to build it.

You can find more details there:

  https://github.com/multipath-tcp/mptcp_net-next/actions/runs/30233020759

Status: failure
Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/acb09ec8b8b1
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1134827

Feel free to reply to this email if you cannot access logs, if you need
some support to fix the error, if this doesn't seem to be caused by your
modifications or if the error is a false positive one.

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)