FAILED: patch "[PATCH] mptcp: pm: ADD_ADDR 0 is not a new address" failed to apply to 5.10-stable tree
Subsystems (3)
[email protected]
maintainerThe patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y
git checkout FETCH_HEAD
git cherry-pick -x 57f86203b41c98b322119dfdbb1ec54ce5e3369b
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2024083025-evoke-catering-3aab@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^..
Possible dependencies:
57f86203b41c ("mptcp: pm: ADD_ADDR 0 is not a new address") 4d25247d3ae4 ("mptcp: bypass in-kernel PM restrictions for non-kernel PMs") 14b06811bec6 ("mptcp: Bypass kernel PM when userspace PM is enabled") a88c9e496937 ("mptcp: do not block subflows creation on errors") 86e39e04482b ("mptcp: keep track of local endpoint still available for each msk") f7d6a237d742 ("mptcp: fix per socket endpoint accounting") b29fcfb54cd7 ("mptcp: full disconnect implementation")59060a47ca50 ("mptcp: clean up harmless false expressions") 3ce0852c86b9 ("mptcp: enforce HoL-blocking estimation")6511882cdd82 ("mptcp: allocate fwd memory separately on the rx and tx path") 765ff425528f ("mptcp: use lockdep_assert_held_once() instead of open-coding it") 1094c6fe7280 ("mptcp: fix possible divide by zero")33c563ad28e3 ("selftests: mptcp: add_addr and echo race test") 2843ff6f36db ("mptcp: remote addresses fullmesh")ee285257a9c1 ("mptcp: drop flags and ifindex arguments") ff5a0b421cb2 ("mptcp: faster active backup recovery")6da14d74e2bd ("mptcp: cleanup sysctl data and helpers")1e1d9d6f119c ("mptcp: handle pending data on closed subflow") 71b7dec27f34 ("mptcp: less aggressive retransmission strategy") 33d41c9cd74c ("mptcp: more accurate timeout")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 57f86203b41c98b322119dfdbb1ec54ce5e3369b Mon Sep 17 00:00:00 2001
From: "Matthieu Baerts (NGI0)" <[email protected]>
Date: Wed, 28 Aug 2024 08:14:37 +0200
Subject: [PATCH] mptcp: pm: ADD_ADDR 0 is not a new address
The ADD_ADDR 0 with the address from the initial subflow should not be considered as a new address: this is not something new. If the host receives it, it simply means that the address is available again.
When receiving an ADD_ADDR for the ID 0, the PM already doesn't consider it as new by not incrementing the 'add_addr_accepted' counter. But the 'accept_addr' might not be set if the limit has already been reached:
this can be bypassed in this case. But before, it is important to check that this ADD_ADDR for the ID 0 is for the same address as the initial subflow. If not, it is not something that should happen, and the ADD_ADDR can be ignored.
Note that if an ADD_ADDR is received while there is already a subflow opened using the same address, this ADD_ADDR is ignored as well. It means that if multiple ADD_ADDR for ID 0 are received, there will not be any duplicated subflows created by the client.
net/mptcp/pm.c +3 -1
@@ -226,7 +226,9 @@ void mptcp_pm_add_addr_received(const struct sock *ssk, }else {__MPTCP_INC_STATS (sock_net ((struct sock *)msk),MPTCP_MIB_ADDADDRDROP ); } - }else if (!READ_ONCE (pm->accept_addr)) { +/* id0 should not have a different address */ + }else if ((addr->id ==0 && !mptcp_pm_nl_is_init_remote_addr (msk, addr)) || + (addr->id >0 && !READ_ONCE (pm->accept_addr))) {mptcp_pm_announce_addr (msk, addr, true);mptcp_pm_add_addr_send_ack (msk); }else if (mptcp_pm_schedule_work (msk,MPTCP_PM_ADD_ADDR_RECEIVED )) {
net/mptcp/pm_netlink.c +9 -0
@@ -760,6 +760,15 @@ static void mptcp_pm_nl_add_addr_received(struct mptcp_sock *msk) } } +bool mptcp_pm_nl_is_init_remote_addr (struct mptcp_sock *msk, +const struct mptcp_addr_info *remote) +{ +struct mptcp_addr_info mpc_remote; + +remote_address ((struct sock_common *)msk, &mpc_remote); +return mptcp_addresses_equal (&mpc_remote, remote, remote->port); +} +void mptcp_pm_nl_addr_send_ack (struct mptcp_sock *msk) {struct mptcp_subflow_context *subflow;
net/mptcp/protocol.h +2 -0
@@ -993,6 +993,8 @@ void mptcp_pm_add_addr_received(const struct sock *ssk,void mptcp_pm_add_addr_echoed (struct mptcp_sock *msk,const struct mptcp_addr_info *addr);void mptcp_pm_add_addr_send_ack (struct mptcp_sock *msk); +bool mptcp_pm_nl_is_init_remote_addr (struct mptcp_sock *msk, +const struct mptcp_addr_info *remote);void mptcp_pm_nl_addr_send_ack (struct mptcp_sock *msk);void mptcp_pm_rm_addr_received (struct mptcp_sock *msk,const struct mptcp_rm_list *rm_list);
Matthieu Baerts
maintainerHi Greg,
Quoted 5 lines · On 30/08/2024 12:26, [email protected] wrote:
The patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
Thank you for the notification!
(...)
Quoted 19 lines
------------------ original commit in Linus's tree ------------------
From
57f86203b41c98b322119dfdbb1ec54ce5e3369bMon Sep 17 00:00:00 2001
From: "Matthieu Baerts (NGI0)" <[email protected]>
Date: Wed, 28 Aug 2024 08:14:37 +0200
Subject: [PATCH] mptcp: pm:ADD_ADDR0 is not a new addressThe
ADD_ADDR0 with the address from the initial subflow should not be considered as a new address: this is not something new. If the host receives it, it simply means that the address is available again.When receiving an
ADD_ADDRfor the ID 0, the PM already doesn't consider it as new by not incrementing the 'add_addr_accepted' counter. But the 'accept_addr' might not be set if the limit has already been reached:
this can be bypassed in this case. But before, it is important to check that thisADD_ADDRfor the ID 0 is for the same address as the initial subflow. If not, it is not something that should happen, and theADD_ADDRcan be ignored.
Quoted 6 lines
Note that if an
ADD_ADDRis received while there is already a subflow opened using the same address, thisADD_ADDRis ignored as well. It means that if multipleADD_ADDRfor ID 0 are received, there will not be any duplicated subflows created by the client.Fixes d0876b2284cf ("mptcp: add the incoming RM_ADDR support")
The code is too different in v5.10, and I don't think it is worth it to have this small fix in v5.10.
Cheers,
Matt
Signature · 1 line
Sponsored by the NGI0 Core fund.