On NIPA, the new test validating the special case for the C-flag failed
a few times, e.g.

  102 default limits, server deny join id 0
        syn rx                 [FAIL] got 0 JOIN[s] syn rx expected 2
  Server ns stats
  TcpPassiveOpens                 1                  0.0
  TcpInSegs                       9                  0.0
  TcpOutSegs                      10                 0.0
  TcpExtTW                        1                  0.0
  TcpExtTCPPureAcks               5                  0.0
  TcpExtTCPOrigDataSent           3                  0.0
  TcpExtTCPDelivered              3                  0.0
  MPTcpExtMPCapableSYNRX          1                  0.0
  MPTcpExtMPCapableACKRX          1                  0.0
  MPTcpExtAddAddrTx               1                  0.0
  MPTcpExtEchoAdd                 1                  0.0
  Client ns stats
  TcpActiveOpens                  1                  0.0
  TcpInSegs                       10                 0.0
  TcpOutSegs                      9                  0.0
  TcpExtTCPPureAcks               6                  0.0
  TcpExtTCPOrigDataSent           3                  0.0
  TcpExtTCPDelivered              4                  0.0
  MPTcpExtMPCapableSYNTX          1                  0.0
  MPTcpExtMPCapableSYNACKRX       1                  0.0
  MPTcpExtAddAddr                 1                  0.0
  MPTcpExtEchoAddTx               1                  0.0
        synack rx              [FAIL] got 0 JOIN[s] synack rx expected 2
        ack rx                 [FAIL] got 0 JOIN[s] ack rx expected 2
        join Rx                [FAIL] see above
        syn tx                 [FAIL] got 0 JOIN[s] syn tx expected 2
        join Tx                [FAIL] see above

I had a suspicion about what the issue could be: the ADD_ADDR might have
been received with a delay, not when switching to 'fully-established'.
The issue was not easy to reproduce on my side, but when I did, the
packet capture shown that the ADD_ADDR can indeed be received with a
delay, and the client would not try to establish subflows to it as
expected.

Patch 1 fixes that, simply by not marking the endpoints as 'used' in the
C-flag case, when looking at creating subflows to the remote initial IP
address and port: in this case, there is no need to try.

Patches 2 to 5 are not directly related, but seen when working on patch
7: they fix subtests not being marked as 'skipped' on older kernels.

Patches 6 and 7 are for net-next:

- The first one avoids iterating over all endpoints just to check if one
  of them has the 'fullmesh' flag.

- The second one clarifies what is done when an ADD_ADDR is received and
  there are endpoints with the fullmesh flag: only these endpoints are
  used, even if there are none defined for this address family.

Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Matthieu Baerts (NGI0) (7):
      mptcp: pm: in-kernel: C-flag: handle late ADD_ADDR
      selftests: mptcp: join: mark 'flush re-add' as skipped if not supported
      selftests: mptcp: join: mark 'delete re-add signal' as skipped if not supported
      selftests: mptcp: join: mark implicit tests as skipped if not supported
      selftests: mptcp: join: mark laminar tests as skipped if not supported
      mptcp: pm: in-kernel: record fullmesh endp nb
      mptcp: pm: in kernel: only use fullmesh endp if any

 include/uapi/linux/mptcp.h                      |  3 +-
 net/mptcp/pm_kernel.c                           | 42 ++++++++++++++++++++++---
 net/mptcp/protocol.h                            |  1 +
 net/mptcp/sockopt.c                             |  2 ++
 tools/testing/selftests/net/mptcp/mptcp_join.sh | 24 ++++++++------
 5 files changed, 57 insertions(+), 15 deletions(-)
---
base-commit: 3afc295b5e6e698696cf1fd75db194db2c7f64cd
change-id: 20251003-c-flag-add-addr-delay-4e9e57789c36

Best regards,
-- 
Matthieu Baerts (NGI0) <matttbe@kernel.org>

Hi Matthieu,

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): Unstable: 1 failed test(s): selftest_simult_flows 🔴
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Success! ✅
- 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/18347885638

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


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)