[PATCH mptcp-next v5 0/6] mptcp: convert to sockopt_lock_sock

Gang Yan posted 6 patches 2 days, 18 hours ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/multipath-tcp/mptcp_net-next tags/patchew/20260522-sockopt._5Flock-v5-0-108629a46e98@kylinos.cn
net/core/filter.c                                  |   6 +
net/mptcp/sockopt.c                                | 133 ++++++++++++---------
tools/testing/selftests/bpf/prog_tests/mptcp.c     |  64 ++++++++++
.../testing/selftests/bpf/progs/mptcp_setsockopt.c |  71 +++++++++++
4 files changed, 220 insertions(+), 54 deletions(-)
[PATCH mptcp-next v5 0/6] mptcp: convert to sockopt_lock_sock
Posted by Gang Yan 2 days, 18 hours ago
Hi Maintainers,

This patch series fixes locking issues in the sockopt path and adds
support for setting MPTCP sockopts in BPF context.

Patch 1 can avoid accidentally introducing sleeping operations inside
the lock_sock_fast() critical section like b5c52908d5("mptcp: fix
scheduling with atomic in timestamp sockopt") does.

Although patches 4 and 5 are marked DO-NOT-MERGE, I think they are
ready for upstream submission, reviews are welcome.

Thanks
Gang

Signed-off-by: Gang Yan <yangang@kylinos.cn>
---
Changelog:
v5:
  - Split patch 1 into two patches, one is to replace lock_sock_fast
    with lock_sock to avoid 'sleeping in atomic context' issue in
    regular path, and another one is using 'sockopt_lock_sock' for
    mptcp socket like TCP does.
  - Patch 3 prevents the sleeping issue from requiring ssks' lock
    in BPF context, It will return -EOPNOTSUPP when application/BPF
    programs trip on this.
  - Patch 4 and 5 are temporary patches used to verify the validity
    of the above functions.
v4:
  - As sashiko said, when processing BPF setsockopt requests, the
    msk is already locked, but we need to use lock_sock() to
    protect ssk. If we use sockopt_lock_sock(ssk), it will return
    without acquiring the lock.
  - In 'mptcp_setsockopt_sol_tcp_congestion', the load of
    'tcp_set_congestion_control' is changed from 'true' to
    '!has_current_bpf_ctx()' like tcp does. This determines whether
    tcp_ca_find() or tcp_ca_find_autoload() is called. I agree we
    should keep consistent with the TCP implementation. 
  Link: https://patch.msgid.link/20260509-sockopt_lock-v4-0-33f3a1c4d7a0@kylinos.cn

v3:
  - Remove the special symbols in v2.
  - Use sockopt_ns_capable to replace ns_capable.
  Link: https://lore.kernel.org/r/20260506-sockopt_lock-v3-0-06bd417c6d63@kylinos.cn

v2:
  Link: https://patchwork.kernel.org/project/mptcp/patch/20260422091927.77770-3-gang.yan@linux.dev/

---
Gang Yan (6):
      mptcp: replace lock_sock_fast with lock_sock in sockopt
      mptcp: use sockopt_lock/release_sock in sockopt
      mptcp: use sockopt_ns_capable in congestion control
      mptcp: reject sockopt requiring ssks' lock in BPF context
      DO-NOT-MERGE: mptcp: allow set some sockopt in BPF context
      DO-NOT-MERGE: selftest: bpf: set mptcp sockopt in BPF context

 net/core/filter.c                                  |   6 +
 net/mptcp/sockopt.c                                | 133 ++++++++++++---------
 tools/testing/selftests/bpf/prog_tests/mptcp.c     |  64 ++++++++++
 .../testing/selftests/bpf/progs/mptcp_setsockopt.c |  71 +++++++++++
 4 files changed, 220 insertions(+), 54 deletions(-)
---
base-commit: aa15c271d79edde595fb6f4eedb52fbc16325a83
change-id: 20260506-sockopt_lock-c46837d6d9d7

Best regards,
-- 
Gang Yan <yangang@kylinos.cn>
Re: [PATCH mptcp-next v5 0/6] mptcp: convert to sockopt_lock_sock
Posted by MPTCP CI 2 days, 16 hours ago
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): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Unstable: 1 failed test(s): packetdrill_dss ⚠️ 
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/26280262996

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


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)