Hi Greg,
On 26/02/2024 14:18, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
>
> The patch below does not apply to the 5.15-stable tree.
(...)
> Possible dependencies:
>
> 045e9d812868 ("mptcp: fix duplicate subflow creation")
> b9d69db87fb7 ("mptcp: let the in-kernel PM use mixed IPv4 and IPv6 addresses")
> bedee0b56113 ("mptcp: address lookup improvements")
> 4638de5aefe5 ("mptcp: handle local addrs announced by userspace PMs")
> c682bf536cf4 ("mptcp: add pm_nl_pernet helpers")
> 4cf86ae84c71 ("mptcp: strict local address ID selection")
> d045b9eb95a9 ("mptcp: introduce implicit endpoints")
> aaa25a2fa796 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net")
(...)
> From 045e9d812868a2d80b7a57b224ce8009444b7bbc Mon Sep 17 00:00:00 2001
> From: Paolo Abeni <pabeni@xxxxxxxxxx>
> Date: Thu, 15 Feb 2024 19:25:33 +0100
> Subject: [PATCH] mptcp: fix duplicate subflow creation
>
> Fullmesh endpoints could end-up unexpectedly generating duplicate
> subflows - same local and remote addresses - when multiple incoming
> ADD_ADDR are processed before the PM creates the subflow for the local
> endpoints.
>
> Address the issue explicitly checking for duplicates at subflow
> creation time.
>
> To avoid a quadratic computational complexity, track the unavailable
> remote address ids in a temporary bitmap and initialize such bitmap
> with the remote ids of all the existing subflows matching the local
> address currently processed.
>
> The above allows additionally replacing the existing code checking
> for duplicate entry in the current set with a simple bit test
> operation.
FYI, because of the various conflicts, and because the issue is quite
harmless -- duplicated subflows are created, but only when trying to
create a high number of subflows, limited to 8 in v5.15, almost
unnoticed bug so far --, I think it is better not to try to backport
this patch to v5.15.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
