Re: [PATCH export v3 2/4] mptcp: reject joins after fallback in mptcp_is_fully_established

[Matthieu Baerts <matttbe@kernel.org>]

On 14/08/2026 18:49, Matthieu Baerts wrote:
> Hi Paolo,
> 
> On 14/08/2026 13:06, Paolo Abeni wrote:
>> On 8/14/26 11:09 AM, Matthieu Baerts wrote:
>>> 14 Aug 2026 10:43:41 Paolo Abeni <pabeni@redhat.com>:
>>>> It's not clear to me what actually goes wrong and how. Do you have handy
>>>> a event sequence or stack trace demonstrating the critical scenario?
>>>
>>> Indeed, better with packetdrill scripts:
>>>
>>> https://github.com/chrisocean716-star/packetdrill/blob/bf9be7a7bee3687500444b284a9db2a0009a5252/gtests/net/mptcp/dss/dss_drop_after_data_fallback_server.pkt
>>>
>>> => A fallback is done, a subflow can be initiated, then rejected.
>>>
>>>
>>> https://github.com/chrisocean716-star/packetdrill/blob/fed57fab92c407eb433acdb8c8ce72bd8e3e2f37/gtests/net/mptcp/mp_join/mp_join_server_after_fallback.pkt
>>>
>>> => The MP_FAIL is partially ignored if received before being in fully
>>> established state.
>>
>> Thanks!
>>
>> I'm pretty sure there is a miss-intepretation of the 2nd case.
> 
> Thank you for having checked!
> 
>> The problem is not with `msk->fully_established`. AFAICS
>> msk->fully_established is true when the MP_FAIL is receive.
>>
>> The passive msk socket sets it at MPC ACK reception.
> 
> Indeed, I should have checked the code instead of only reading the
> comments from this test :)
> 
>> The problem is that, at MP_FAIL reception, the infinite mapping is not
>> sent immediately, but it's scheduled with the next xmit, and until such
>> point the msk does not perform the fallback.
>>
>> I think a proper solution would be bounding MP_FAIL (reply) and infinite
>> mapping in the same ack.
>>
>> As noted by Gang, it may require a new helper (build on top of the
>> tcp_send_ack).
> Sounds good to me!
> 
> What about the 1st case (fallback)?
> 
> Would it help to reset msk->fully_established in
> __mptcp_try_fallback()?(while holding the data_lock? not even sure it is
> needed at that stage)
> But here, we will also need to update subflow_token_join_request() to
> check mptcp_is_fully_established, or even mptcp_can_accept_new_subflow.
> (I can send a quick RFC patch)

Sent:
https://lore.kernel.org/20260814-mptcp-reset-mpj-early-v1-0-3ca3260f9474@kernel.org

> It would also benefit to the in-kernel PM and others places using
> mptcp_is_fully_established(). subflow->fully_established doesn't need to
> be reset.
> 
> Cheers,
> Matt

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