From: Matthieu Baerts <matttbe@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>,
Chenguang Zhao <chenguang.zhao@linux.dev>,
mptcp@lists.linux.dev
Cc: Chenguang Zhao <zhaochenguang@kylinos.cn>
Subject: Re: [PATCH export v3 2/4] mptcp: reject joins after fallback in mptcp_is_fully_established
Date: Wed, 12 Aug 2026 17:32:21 +0200 [thread overview]
Message-ID: <41078a8c-00c7-4cb1-8e57-237b4ea6c2f0@kernel.org> (raw)
In-Reply-To: <1d7c56b9-00c1-4550-a403-c3d704259267@redhat.com>
Hi Paolo, Chenguang,
On 12/08/2026 11:45, Paolo Abeni wrote:
> On 8/12/26 7:46 AM, Chenguang Zhao wrote:
>> From: Chenguang Zhao <zhaochenguang@kylinos.cn>
>>
>> After fallback, treat the connection as not fully established so later
>> MP_JOIN attempts are rejected.
@Chenguang: please first reply to the questions and comments from the
previous versions, then only send a new version when the discussions are
over.
>> Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>
>> ---
>> net/mptcp/protocol.h | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
>> index 7e168e450fb0..bf2483a7ed92 100644
>> --- a/net/mptcp/protocol.h
>> +++ b/net/mptcp/protocol.h
>> @@ -957,8 +957,11 @@ static inline void mptcp_start_tout_timer(struct sock *sk)
>>
>> static inline bool mptcp_is_fully_established(struct sock *sk)
>> {
>> + struct mptcp_sock *msk = mptcp_sk(sk);
>> +
>> return inet_sk_state_load(sk) == TCP_ESTABLISHED &&
>> - READ_ONCE(mptcp_sk(sk)->fully_established);
>> + READ_ONCE(msk->fully_established) &&
>> + !test_bit(MPTCP_FALLBACK_DONE, &msk->flags);
>
> Does the above improve actually anything? The test is inherently racy,
> as lack the fallback_lock, and AFAICS all critical paths have already
> explicit checks under such lock, see i.e. mptcp_finish_join().
Indeed, the fallback lock is missing.
Note: Chenguang is looking at a bug where, when an MP_FAIL is received
before being in fully_established, the kernel accept going to fully
established, and creating new subflows, then reject them once done.
Same when receiving a 4th packet without MPTCP options.
I think the MP_FAIL should do a fallback if possible, but it is probably
also required to check the fallback status or something similar when
receiving an MPJ.
> I would prefer avoiding additional conditionals, if not well reasoned.
Agreed, the commit messages in this series are not explaining (enough)
the reason and the context.
BTW, Chenguang, please use 'mptcp-net' for fixes (and mptcp-next for
features). Also fixes should have a Fixes tag.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
next prev parent reply other threads:[~2026-08-12 15:32 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 5:46 [PATCH export v3 0/4] mptcp: fix TCP fallback on single-subflow MP_FAIL Chenguang Zhao
2026-08-12 5:46 ` [PATCH export v3 1/4] mptcp: add MPFailFallback MIB Chenguang Zhao
2026-08-12 5:46 ` [PATCH export v3 2/4] mptcp: reject joins after fallback in mptcp_is_fully_established Chenguang Zhao
2026-08-12 9:45 ` Paolo Abeni
2026-08-12 15:32 ` Matthieu Baerts [this message]
2026-08-13 9:32 ` gang.yan
2026-08-13 17:42 ` Matthieu Baerts
2026-08-14 3:02 ` gang.yan
2026-08-14 15:45 ` Matthieu Baerts
2026-08-14 8:43 ` Paolo Abeni
2026-08-14 9:09 ` Matthieu Baerts
2026-08-14 11:06 ` Paolo Abeni
2026-08-14 16:49 ` Matthieu Baerts
2026-08-14 18:34 ` Matthieu Baerts
2026-08-13 8:45 ` Chenguang Zhao
2026-08-13 18:06 ` Matthieu Baerts
2026-08-12 5:46 ` [PATCH export v3 3/4] mptcp: reset subflow on MP_FAIL when OoO queue is non-empty Chenguang Zhao
2026-08-12 6:07 ` sashiko-bot
2026-08-12 10:02 ` Paolo Abeni
2026-08-13 8:45 ` Chenguang Zhao
2026-08-12 5:46 ` [PATCH export v3 4/4] mptcp: fallback to TCP on MP_FAIL with a single subflow Chenguang Zhao
2026-08-12 10:43 ` Paolo Abeni
2026-08-13 8:48 ` Chenguang Zhao
2026-08-12 10:47 ` Paolo Abeni
2026-08-13 8:50 ` Chenguang Zhao
2026-08-12 6:57 ` [PATCH export v3 0/4] mptcp: fix TCP fallback on single-subflow MP_FAIL MPTCP CI
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41078a8c-00c7-4cb1-8e57-237b4ea6c2f0@kernel.org \
--to=matttbe@kernel.org \
--cc=chenguang.zhao@linux.dev \
--cc=mptcp@lists.linux.dev \
--cc=pabeni@redhat.com \
--cc=zhaochenguang@kylinos.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.