Hi Sasha,
Thank you for having suggested this patch.
On 03/04/2025 21:01, Sasha Levin wrote:
From: Paolo Abeni pabeni@redhat.com
[ Upstream commit bc68b0efa1bf923cef1294a631d8e7416c7e06e4 ]
After commit c2e6048fa1cf ("mptcp: fix race in release_cb") we can move the whole MPTCP rx path under the socket lock leveraging the release_cb.
We can drop a bunch of spin_lock pairs in the receive functions, use a single receive queue and invoke __mptcp_move_skbs only when subflows ask for it.
This will allow more cleanup in the next patch.
Some changes are worth specific mention:
The msk rcvbuf update now always happens under both the msk and the subflow socket lock: we can drop a bunch of ONCE annotation and consolidate the checks.
When the skbs move is delayed at msk release callback time, even the msk rcvbuf update is delayed; additionally take care of such action in __mptcp_move_skbs().
Signed-off-by: Paolo Abeni pabeni@redhat.com Reviewed-by: Mat Martineau martineau@kernel.org Signed-off-by: Matthieu Baerts (NGI0) matttbe@kernel.org Link: https://patch.msgid.link/20250218-net-next-mptcp-rx-path-refactor-v1-3-4a47d... Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org
With Mat, we are unsure why this patch has been selected to be backported up to v6.6. An AUTOSEL patch has been sent for v6.6, v6.12, v6.13 and v6.14. We think it would be better not to backport this patch: this is linked to a new feature, and it changes the way the MPTCP socket locks are handled.
Could it then please be possible not to queue this patch to the stable queues?
Cheers, Matt