Re: [PATCH export v3 2/4] mptcp: reject joins after fallback in mptcp_is_fully_established
Matthieu Baerts <[email protected]>
| Newsgroups | dev.linux.lists.mptcp |
|---|---|
| Organization | NGI0 Core |
| Message-ID | <[email protected]> |
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 <[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) Sent: https://lore.kernel.org/[email protected] > 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.