From: Matthieu Baerts <matttbe@kernel.org>
To: Chenguang Zhao <chenguang.zhao@linux.dev>,
Paolo Abeni <pabeni@redhat.com>,
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: Thu, 13 Aug 2026 20:06:26 +0200 [thread overview]
Message-ID: <d7269e8a-b9a5-4a93-ab4e-92d677fef09b@kernel.org> (raw)
In-Reply-To: <91381212-7d87-438b-a04b-50a3be4c5388@linux.dev>
Hi Chenguang,
On 13/08/2026 10:45, Chenguang Zhao wrote:
>
> 在 2026/8/12 17:45, Paolo Abeni 写道:
>> 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.
>>>
>>> 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().
>>
>> I would prefer avoiding additional conditionals, if not well reasoned.
>>
>> /P
>>
> Hi Paolo
>
> You are right: the extra FALLBACK_DONE check in
> mptcp_is_fully_established() does not actually improve anything.
> It is read without fallback_lock, so it is racy. The paths that must
> not complete a join after MP_FAIL already reject it under that lock
> via allow_subflows, e.g. mptcp_finish_join() / __mptcp_finish_join().
> I will drop this patch in the next revision and leave
> mptcp_is_fully_established() unchanged.
How do you plan to deal with the case where a fallback has been done
while being in fully established mode?
Could we add WRITE_ONCE(msk->fully_established, false) in
__mptcp_try_fallback()? I guess it is acceptable because
__mptcp_finish_join will check allow_subflows under lock, no?
Or maybe we accept this behaviour?
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
next prev parent reply other threads:[~2026-08-13 18:06 UTC|newest]
Thread overview: 19+ 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
2026-08-13 9:32 ` gang.yan
2026-08-13 17:42 ` Matthieu Baerts
2026-08-13 8:45 ` Chenguang Zhao
2026-08-13 18:06 ` Matthieu Baerts [this message]
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=d7269e8a-b9a5-4a93-ab4e-92d677fef09b@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.