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

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 <[email protected]>:
>>> 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)

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
-- 
Sponsored by the NGI0 Core fund.