From: sashiko-bot@kernel.org
To: "Geliang Tang" <geliang@kernel.org>
Cc: mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next v12 06/10] mptcp: align FIN handling with TCP via SOCK_DONE
Date: Mon, 31 Aug 2026 10:53:06 +0000 [thread overview]
Message-ID: <20260831105307.1459C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <916f17d4a2b1e948fd89634e57552243564a0d59.1788171508.git.tanggeliang@kylinos.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Memory barrier API violation: smp_mb__before_atomic() is used before a non-atomic bitwise operation, which fails to emit a hardware memory barrier on architectures like LoongArch, allowing store-store reordering and breaking synchronization.
--
commit ed77cdb78ed1ea97ec780c81ea48c8eba994517c
Author: Geliang Tang <geliang@kernel.org>
Subject: mptcp: align FIN handling with TCP via SOCK_DONE
This commit aligns MPTCP's FIN handling with TCP by using the SOCK_DONE flag
to mark FIN reception alongside RCV_SHUTDOWN. It updates mptcp_inq_hint() and
mptcp_recvmsg() to check SOCK_DONE, ensuring the FIN handling only triggers
on a real DATA_FIN.
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index 9bcca31501e7d..f970b92429726 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -736,6 +736,7 @@ static void mptcp_check_data_fin(struct sock *sk)
>
> WRITE_ONCE(sk->sk_shutdown, sk->sk_shutdown | RCV_SHUTDOWN);
> smp_mb__before_atomic(); /* SHUTDOWN must be visible first */
> + sock_set_flag(sk, SOCK_DONE);
[Severity: High]
Does this memory barrier adequately protect the store to SOCK_DONE on weakly
ordered architectures?
According to the atomic operations documentation, smp_mb__before_atomic() must
only be used immediately before atomic RMW operations. Since sock_set_flag()
uses __set_bit() which is non-atomic, the barrier might not emit a hardware
memory barrier on architectures like LoongArch (where it is defined merely as
a compiler barrier).
If the CPU reorders the non-atomic stores, SOCK_DONE could become visible
before the ack_seq update in mptcp_check_data_fin(). A concurrent lockless
reader in mptcp_inq_hint() executing smp_rmb() might see the new SOCK_DONE
flag but read a stale ack_seq.
Could this cause hint_val to undercount by 1 byte and potentially hang
TLS/BPF consumers waiting for the final byte? Would it be safer to use
smp_wmb() or smp_mb() here to guarantee store-store ordering?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1788171508.git.tanggeliang@kylinos.cn?part=6
next prev parent reply other threads:[~2026-08-31 10:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 10:27 [PATCH mptcp-next v12 00/10] Reduce the differences between TCP and MPTCP for TLS usage Geliang Tang
2026-08-31 10:27 ` [PATCH mptcp-next v12 01/10] mptcp: drop the mptcp_ooo_try_coalesce() helper Geliang Tang
2026-08-31 10:27 ` [PATCH mptcp-next v12 02/10] mptcp: drop the cant_coalesce CB field Geliang Tang
2026-08-31 10:27 ` [PATCH mptcp-next v12 03/10] mptcp: remove CB offset field Geliang Tang
2026-08-31 10:27 ` [PATCH mptcp-next v12 04/10] mptcp: sync mptcp skb cb layout with tcp one Geliang Tang
2026-08-31 10:27 ` [PATCH mptcp-next v12 05/10] mptcp: defer read_sock cleanup to mptcp_worker Geliang Tang
2026-08-31 10:27 ` [PATCH mptcp-next v12 06/10] mptcp: align FIN handling with TCP via SOCK_DONE Geliang Tang
2026-08-31 10:53 ` sashiko-bot [this message]
2026-08-31 10:27 ` [PATCH mptcp-next v12 07/10] mptcp: implement peek_len for proto_ops Geliang Tang
2026-08-31 10:27 ` [PATCH mptcp-next v12 08/10] mptcp: add sendmsg_locked to proto_ops Geliang Tang
2026-08-31 10:27 ` [PATCH mptcp-next v12 09/10] mptcp: track app-limited state in mptcp_sendmsg Geliang Tang
2026-08-31 10:27 ` [PATCH mptcp-next v12 10/10] selftests: mptcp: sockopt: check app_limited Geliang Tang
2026-08-31 11:36 ` [PATCH mptcp-next v12 00/10] Reduce the differences between TCP and MPTCP for TLS usage 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=20260831105307.1459C1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=geliang@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
/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.