Message ID | 20240816-mptcp-dup-close-evt-v2-7-8a33f6617f5c@kernel.org (mailing list archive) |
---|---|
State | Accepted, archived |
Commit | dfe065fa0ed148847dbc6bd7425a0a6356607233 |
Delegated to: | Matthieu Baerts |
Headers | show |
Series | mptcp: pm: fix re-re-create the ID 0 endpoint | expand |
Context | Check | Description |
---|---|---|
matttbe/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 24 lines checked |
matttbe/shellcheck | success | MPTCP selftests files have not been modified |
matttbe/build | success | Build and static analysis OK |
matttbe/KVM_Validation__normal | success | Success! ✅ |
matttbe/KVM_Validation__debug | success | Success! ✅ |
matttbe/KVM_Validation__btf__only_bpftest_all_ | success | Success! ✅ |
On 16/08/2024 14:02, Matthieu Baerts (NGI0) wrote: > 'local_addr_used' and 'add_addr_accepted' are decremented for addresses > not related to the initial subflow (ID0), because the source and > destination addresses of the initial subflows are known from the > beginning: they don't count as "additional local address being used" or > "ADD_ADDR being accepted". > > It is then required not to increment them when the entrypoint used by > the initial subflow is removed and re-added during a connection. Without > this modification, this entrypoint cannot be removed and re-added more > than once. > > Reported-by: Arınç ÜNAL <arinc.unal@arinc9.com> > Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/512 > Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking") > Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com> Thanks a lot! Arınç
diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c index 952982ebac17..6a05eacd59b3 100644 --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -619,12 +619,13 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) fullmesh = !!(local.flags & MPTCP_PM_ADDR_FLAG_FULLMESH); - msk->pm.local_addr_used++; __clear_bit(local.addr.id, msk->pm.id_avail_bitmap); /* Special case for ID0: set the correct ID */ if (local.addr.id == msk->mpc_endpoint_id) local.addr.id = 0; + else /* local_addr_used is not decr for ID 0 */ + msk->pm.local_addr_used++; nr = fill_remote_addresses_vec(msk, &local.addr, fullmesh, addrs); if (nr == 0) @@ -754,7 +755,9 @@ static void mptcp_pm_nl_add_addr_received(struct mptcp_sock *msk) spin_lock_bh(&msk->pm.lock); if (sf_created) { - msk->pm.add_addr_accepted++; + /* add_addr_accepted is not decr for ID 0 */ + if (remote.id) + msk->pm.add_addr_accepted++; if (msk->pm.add_addr_accepted >= add_addr_accept_max || msk->pm.subflows >= subflows_max) WRITE_ONCE(msk->pm.accept_addr, false);
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <arinc.unal@arinc9.com> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/512 Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking") Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> --- net/mptcp/pm_netlink.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)