With TCP Fast Open on an MPTCP listener, if the server application writes data while the passive subflow is still in SYN_RECV (after consuming the client's SYN data but before the MP_CAPABLE third ACK arrives), __mptcp_subflow_active() refuses transmission and the data is queued into the msk write queue. When the MPC third ACK arrives, check_fully_established() marks the subflow established, but because the third ACK carries no DSS data, the queued bytes remain stranded until the peer sends more data. Fix this by: 1. Invoking __mptcp_check_push() in check_fully_established() when subflow->is_mptfo is set. 2. Setting MPTCP_PUSH_PENDING and scheduling the MPTCP worker in subflow_state_change() so that once the underlying subflow transitions to TCP_ESTABLISHED, pending queued bytes are immediately flushed. Reported-by: Petar Sakic Closes: https://lore.kernel.org/netdev/CAFPPu1gU2Y-D+d4i3F0MoNkYK+e1U+=X3qf6QycjfKBw+8snPg@mail.gmail.com/ Fixes: e00b63056fb4 ("fastopen: only mark MPTFO subflows with SYN data") Signed-off-by: T S Rameshkumar --- net/mptcp/options.c | 7 +++++++ net/mptcp/subflow.c | 5 +++++ 2 files changed, 12 insertions(+) diff --git a/net/mptcp/options.c b/net/mptcp/options.c index ce0de02f5..d5238fa11 100644 --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -1042,6 +1042,13 @@ static bool check_fully_established(struct mptcp_sock *msk, struct sock *ssk, mptcp_data_lock((struct sock *)msk); __mptcp_subflow_fully_established(msk, subflow, mp_opt); + /* Passive TFO: the application may have written data while the + * subflow was still in SYN_RECV; __mptcp_subflow_active() refused + * it then and nothing else spools the msk write queue when the + * MPC third ack (no DSS) arrives. Push it now. + */ + if (subflow->is_mptfo) + __mptcp_check_push((struct sock *)msk, ssk); mptcp_data_unlock((struct sock *)msk); check_notify: diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index f0a6725d2..f499073a6 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -1894,6 +1894,11 @@ static void subflow_state_change(struct sock *sk) if (subflow->resetting) return; + if (subflow->is_mptfo) { + set_bit(MPTCP_PUSH_PENDING, &mptcp_sk(parent)->cb_flags); + mptcp_schedule_work(parent); + } + /* as recvmsg() does not acquire the subflow socket for ssk selection * a fin packet carrying a DSS can be unnoticed if we don't trigger * the data available machinery here. -- 2.34.1