| Message ID | 20240816-mptcp-dup-close-evt-v2-0-8a33f6617f5c@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | mptcp: pm: fix re-re-create the ID 0 endpoint | expand |
Hi Matthieu, Thank you for your modifications, that's great! Our CI did some validations and here is its report: - KVM Validation: normal: Success! ✅ - KVM Validation: debug: Unstable: 1 failed test(s): packetdrill_regressions
Hi Matthieu,
Thank you for your modifications, that's great!
Our CI did some validations and here is its report:
- KVM Validation: normal: Success! ✅
- KVM Validation: debug: Success! ✅
- KVM Validation: btf (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/10419016942
Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/de4d0b5876cc
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=880310
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)
Hello, On 16/08/2024 13:01, Matthieu Baerts (NGI0) wrote: > Even more fixes for the in-kernel PM :) > > There are a few Squash-to patches fist: > > - a partial revert for a previous Squash-to patch: probably fine not to > block the send of the original patch then. > > - improve code coverage > > - use the right ID with __mark_subflow_endp_available() > > - small fix for the fullmesh case when re-adding the ID 0 endpoint > > - set the ID for __mark_subflow_endp_available() As discussed on IRC with Mat, I just applied 3 of these Squash-to patches, to be able to send some patches upstream: New patches for t/upstream-net and t/upstream: - 5bc9b44ceee6: "squashed" patch 1/12 in "mptcp: pm: re-using ID of unused removed ADD_ADDR" - cdf9299d9049: "squashed" patch 3/12 in "mptcp: pm: only mark 'subflow' endp as available" - 09ed0d2ad732: "squashed" patch 5/12 in "mptcp: pm: fix RM_ADDR ID for the initial subflow" - Results: 2fda2724156a..1abc61ec2c0d (export-net) - Results: a3cc6d5a9b3f..fa810ad2128f (export) Tests are now in progress: - export-net: https://github.com/multipath-tcp/mptcp_net-next/commit/d7dd870a1134787d390aa69db7ced0885136a864/checks - export: https://github.com/multipath-tcp/mptcp_net-next/commit/4fc5ed8e59b495fb79d651028681d4eca5354284/checks Cheers, Matt
On Fri, 16 Aug 2024, Matthieu Baerts (NGI0) wrote: > Even more fixes for the in-kernel PM :) > > There are a few Squash-to patches fist: > > - a partial revert for a previous Squash-to patch: probably fine not to > block the send of the original patch then. > > - improve code coverage > > - use the right ID with __mark_subflow_endp_available() > > - small fix for the fullmesh case when re-adding the ID 0 endpoint > > - set the ID for __mark_subflow_endp_available() > > Then a few more fixes: > > - avoid the RM_SUBFLOW MIB counter to be incremented twice > > - fix re-re-creation of the ID 0 endpoint > > - validate that in the selftests > > - avoid duplicated SUB_CLOSED events > > - validate that in the selftests > > - ADD_ADDR 0 is not taking into account by the 'add_addr_accepted' > counter, then it should bypass 'accept_addr' & make sure ADD_ADDR 0 is > not sent with a new address > > - validate that in the selftests > > Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> > --- > Changes in v2: > - New squash-to patches after new issue reported by Arınç: patch 3,5/12. > - Patch 8/12 is re-creating the ID 0 endpoint 3 times. > - Link to v1: https://lore.kernel.org/r/20240815-mptcp-dup-close-evt-v1-0-5a551d3a66cc@kernel.org > Hi Matthieu - I have one comment for patch 9 that you can add while applying. A more general question for self tests, is there documentation around for our reverse-compatibility goals for the self tests? Reviewed-by: Mat Martineau <martineau@kernel.org>
Hi Mat, On 24/08/2024 02:42, Mat Martineau wrote: > On Fri, 16 Aug 2024, Matthieu Baerts (NGI0) wrote: > >> Even more fixes for the in-kernel PM :) >> >> There are a few Squash-to patches fist: >> >> - a partial revert for a previous Squash-to patch: probably fine not to >> block the send of the original patch then. >> >> - improve code coverage >> >> - use the right ID with __mark_subflow_endp_available() >> >> - small fix for the fullmesh case when re-adding the ID 0 endpoint >> >> - set the ID for __mark_subflow_endp_available() >> >> Then a few more fixes: >> >> - avoid the RM_SUBFLOW MIB counter to be incremented twice >> >> - fix re-re-creation of the ID 0 endpoint >> >> - validate that in the selftests >> >> - avoid duplicated SUB_CLOSED events >> >> - validate that in the selftests >> >> - ADD_ADDR 0 is not taking into account by the 'add_addr_accepted' >> counter, then it should bypass 'accept_addr' & make sure ADD_ADDR 0 is >> not sent with a new address >> >> - validate that in the selftests >> >> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> >> --- >> Changes in v2: >> - New squash-to patches after new issue reported by Arınç: patch 3,5/12. >> - Patch 8/12 is re-creating the ID 0 endpoint 3 times. >> - Link to v1: https://lore.kernel.org/r/20240815-mptcp-dup-close-evt- >> v1-0-5a551d3a66cc@kernel.org >> > > Hi Matthieu - > > I have one comment for patch 9 that you can add while applying. Thank you for the review! > A more general question for self tests, is there documentation around > for our reverse-compatibility goals for the self tests? Not really. I mean, the KSelftests doc mentions [1] that "Kselftest from mainline can be run on older stable kernels", but that's it. For who this doc would be? Would it be specific to MPTCP? (I still need to look at having a CI job regularly validating the stable kernels with the selftests from our export branch) [1] https://docs.kernel.org/dev-tools/kselftest.html > Reviewed-by: Mat Martineau <martineau@kernel.org> New patches for t/upstream-net and t/upstream: - 62ea9befdf81: "squashed" patch 2/12 (with conflicts) in "selftests: mptcp: join: check removing ID 0 endpoint" - 166b2e2e7e55: "squashed" patch 4/12 in "mptcp: pm: reuse ID 0 after delete and re-add" - 3760c0b70fd2: conflict in t/selftests-mptcp-join-validate-MPJ-SYN-TX-MIB-counters - Results: 410328b9177d..48372820bae1 (export-net) - Results: 578465d5bbbe..8a29143c4af9 (export) - 9a20909645a3: mptcp: pm: do not remove already closed subflows - dfe065fa0ed1: mptcp: pm: fix ID 0 endp usage after multiple re-creations - e4aed237e502: selftests: mptcp: join: check re-re-adding ID 0 endp - 67e2bf3f6157: mptcp: avoid duplicated SUB_CLOSED events - 240550f9423b: selftests: mptcp: join: validate event numbers - cac1db6d0b63: mptcp: pm: ADD_ADDR 0 is not a new address - 9ee8e1ef984d: selftests: mptcp: join: check re-re-adding ID 0 signal - 77eef1cce636: conflict in t/selftests-mptcp-join-validate-MPJ-SYN-TX-MIB-counters - Results: 48372820bae1..bbc47d79e5c3 (export-net) - Results: 8a29143c4af9..c94cd4e2e8ed (export) Tests are now in progress: - export-net: https://github.com/multipath-tcp/mptcp_net-next/commit/3e189f6578aa29cfda6c0305cc2e0ba9890440b7/checks - export-net: https://github.com/multipath-tcp/mptcp_net-next/commit/455555bfbecd70ae0502fb68139e3f4f65e91657/checks - export: https://github.com/multipath-tcp/mptcp_net-next/commit/4964e83f255e59f55e09d09a0447e49dcc77d7a3/checks Cheers, Matt
Even more fixes for the in-kernel PM :) There are a few Squash-to patches fist: - a partial revert for a previous Squash-to patch: probably fine not to block the send of the original patch then. - improve code coverage - use the right ID with __mark_subflow_endp_available() - small fix for the fullmesh case when re-adding the ID 0 endpoint - set the ID for __mark_subflow_endp_available() Then a few more fixes: - avoid the RM_SUBFLOW MIB counter to be incremented twice - fix re-re-creation of the ID 0 endpoint - validate that in the selftests - avoid duplicated SUB_CLOSED events - validate that in the selftests - ADD_ADDR 0 is not taking into account by the 'add_addr_accepted' counter, then it should bypass 'accept_addr' & make sure ADD_ADDR 0 is not sent with a new address - validate that in the selftests Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> --- Changes in v2: - New squash-to patches after new issue reported by Arınç: patch 3,5/12. - Patch 8/12 is re-creating the ID 0 endpoint 3 times. - Link to v1: https://lore.kernel.org/r/20240815-mptcp-dup-close-evt-v1-0-5a551d3a66cc@kernel.org --- Matthieu Baerts (NGI0) (12): Squash to "mptcp: pm: re-using ID of unused removed ADD_ADDR" Squash to "selftests: mptcp: join: check removing ID 0 endpoint" Squash to "mptcp: pm: only mark 'subflow' endp as available" Squash to "mptcp: pm: reuse ID 0 after delete and re-add" Squash to "mptcp: pm: fix RM_ADDR ID for the initial subflow" mptcp: pm: do not remove already closed subflows mptcp: pm: fix ID 0 endp usage after multiple re-creations selftests: mptcp: join: check re-re-adding ID 0 endp mptcp: avoid duplicated SUB_CLOSED events selftests: mptcp: join: validate event numbers mptcp: pm: ADD_ADDR 0 is not a new address selftests: mptcp: join: check re-re-adding ID 0 signal net/mptcp/pm.c | 4 +- net/mptcp/pm_netlink.c | 38 +++++-- net/mptcp/protocol.c | 6 ++ net/mptcp/protocol.h | 5 +- tools/testing/selftests/net/mptcp/mptcp_join.sh | 129 ++++++++++++++++++++---- tools/testing/selftests/net/mptcp/mptcp_lib.sh | 4 + 6 files changed, 154 insertions(+), 32 deletions(-) --- base-commit: e2b07354530a5aea0cfc25e7d16094a15f080643 change-id: 20240813-mptcp-dup-close-evt-e4512ec78742 Best regards,