Re: [PATCH AUTOSEL 6.14 20/54] mptcp: move the whole rx path under msk socket lock protection

[Matthieu Baerts <matttbe@kernel.org>]

Hi Paolo,

On 08/04/2025 19:18, Matthieu Baerts wrote:
> Hi Paolo,
> 
> (MPTCP list only)
> 
> 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-4a47d90d7998@kernel.org
>> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
> 
> It is not clear to me why this patch has been selected by AUTOSEL for up
> to 6.6, this is clearly not a fix. Do you think we should ask the stable
> team to drop this patch?
> 
> Having this patch in stable might help for future backports, but I don't
> know if it depends on others.

After discussing this patch with Mat yesterday, we think it would be
safer to ask to drop it from stable. If later we see it is really
needed, this patch can be backported (and probably others from the
series) and properly tested.

I hope there are no objections on that :)

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.