From: gang.yan@linux.dev
To: "Tao Cui" <cui.tao@linux.dev>, mptcp@lists.linux.dev
Cc: matttbe@kernel.org, martineau@kernel.org, geliang@kernel.org,
"Tao Cui" <cuitao@kylinos.cn>
Subject: Re: [RFC PATCH mptcp-next] mptcp: annotate data-races around sysctl reads
Date: Fri, 14 Aug 2026 03:51:04 +0000 [thread overview]
Message-ID: <44897d3c50a4ce9db11d52c19382a2c9f648a62c@linux.dev> (raw)
In-Reply-To: <20260814032749.2222975-1-cui.tao@linux.dev>
August 14, 2026 at 11:27 AM, "Tao Cui" <cui.tao@linux.dev mailto:cui.tao@linux.dev?to=%22Tao%20Cui%22%20%3Ccui.tao%40linux.dev%3E > wrote:
Hi, Tao
Thanks for your patch, but it has been submitted by Matt before in [1].
I think Matt wanted change the PM and sched sysctl from string to atomically,
that may need another patches (READ_ONCE is not enough), right? If no, you can
wait for the other maintainers' reply.
If yes, I still think this patch should keep author as matt, the rest of
others can be yours.
Note: Some patches about sched is only in our export branch, not mainlined,
so it's better to do your work based on it.
[1] https://patchwork.kernel.org/project/mptcp/patch/20260601-mptcp-add-addr6-port-ts-fixes-v2-v1-4-d7c842e80446@kernel.org/
Thanks
Gang
>
> From: Tao Cui <cuitao@kylinos.cn>
>
> #626 plans a READ_ONCE-over-sysctls series for the string sysctls; this
> is the numeric side. Asking whether to send it on its own or fold it in.
>
> The per-netns MPTCP sysctl values (net.mptcp.enabled, add_addr_timeout,
> checksum_enabled, allow_join_initial_addr_port, stale_loss_cnt,
> close_timeout, pm_type) are written from the sysctl handlers and read
> without locking through the ctrl.c accessors.
>
> Add READ_ONCE() on the readers and WRITE_ONCE() on the pm_type store in
> proc_path_manager(), matching what is already done for other mptcp
> fields (fully_established, local_id, remote_id, sysctl_tcp_wmem[0]).
>
> The string sysctls (path_manager, scheduler) are not covered: they need
> atomic replacement, see the tracker below.
>
> KCSAN reproduces the race on net.mptcp.enabled, and the READ_ONCE makes
> it go away:
>
> BUG: KCSAN: data-race in mptcp_is_enabled / proc_dou8vec_minmax
>
> write to 0xffff8f93c18553e9 of 1 bytes by task 214 on cpu 1:
> proc_dou8vec_minmax+0x1b1/0x200
> proc_sys_call_handler+0x268/0x350
> vfs_write+0x423/0x710
>
> read to 0xffff8f93c18553e9 of 1 bytes by task 72 on cpu 0:
> mptcp_is_enabled+0x50/0x60
> mptcp_init_sock+0x2a/0x1c0
> inet_create+0x3f9/0x5a0
>
> value changed: 0x00 -> 0x01
>
> No functional change.
>
> Link: https://github.com/multipath-tcp/mptcp_net-next/issues/626
> Signed-off-by: Tao Cui <cuitao@kylinos.cn>
> ---
> net/mptcp/ctrl.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/net/mptcp/ctrl.c b/net/mptcp/ctrl.c
> index 63c5747f0f63..b0ef6aea4eba 100644
> --- a/net/mptcp/ctrl.c
> +++ b/net/mptcp/ctrl.c
> @@ -50,39 +50,39 @@ static struct mptcp_pernet *mptcp_get_pernet(const struct net *net)
>
> int mptcp_is_enabled(const struct net *net)
> {
> - return mptcp_get_pernet(net)->mptcp_enabled;
> + return READ_ONCE(mptcp_get_pernet(net)->mptcp_enabled);
> }
>
> unsigned int mptcp_get_add_addr_timeout(const struct net *net)
> {
> - return mptcp_get_pernet(net)->add_addr_timeout;
> + return READ_ONCE(mptcp_get_pernet(net)->add_addr_timeout);
> }
>
> int mptcp_is_checksum_enabled(const struct net *net)
> {
> - return mptcp_get_pernet(net)->checksum_enabled;
> + return READ_ONCE(mptcp_get_pernet(net)->checksum_enabled);
> }
>
> int mptcp_allow_join_id0(const struct net *net)
> {
> - return mptcp_get_pernet(net)->allow_join_initial_addr_port;
> + return READ_ONCE(mptcp_get_pernet(net)->allow_join_initial_addr_port);
> }
>
> unsigned int mptcp_stale_loss_cnt(const struct net *net)
> {
> - return mptcp_get_pernet(net)->stale_loss_cnt;
> + return READ_ONCE(mptcp_get_pernet(net)->stale_loss_cnt);
> }
>
> unsigned int mptcp_close_timeout(const struct sock *sk)
> {
> if (sock_flag(sk, SOCK_DEAD))
> return TCP_TIMEWAIT_LEN;
> - return mptcp_get_pernet(sock_net(sk))->close_timeout;
> + return READ_ONCE(mptcp_get_pernet(sock_net(sk))->close_timeout);
> }
>
> int mptcp_get_pm_type(const struct net *net)
> {
> - return mptcp_get_pernet(net)->pm_type;
> + return READ_ONCE(mptcp_get_pernet(net)->pm_type);
> }
>
> const char *mptcp_get_path_manager(const struct net *net)
> @@ -230,7 +230,7 @@ static int proc_path_manager(const struct ctl_table *ctl, int write,
> pm_type = MPTCP_PM_TYPE_KERNEL;
> else if (strncmp(pm_name, "userspace", MPTCP_PM_NAME_MAX) == 0)
> pm_type = MPTCP_PM_TYPE_USERSPACE;
> - pernet->pm_type = pm_type;
> + WRITE_ONCE(pernet->pm_type, pm_type);
> }
> }
>
> --
> 2.43.0
>
next prev parent reply other threads:[~2026-08-14 3:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 3:27 [RFC PATCH mptcp-next] mptcp: annotate data-races around sysctl reads Tao Cui
2026-08-14 3:51 ` gang.yan [this message]
2026-08-14 5:26 ` Tao Cui
2026-08-14 4:31 ` 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=44897d3c50a4ce9db11d52c19382a2c9f648a62c@linux.dev \
--to=gang.yan@linux.dev \
--cc=cui.tao@linux.dev \
--cc=cuitao@kylinos.cn \
--cc=geliang@kernel.org \
--cc=martineau@kernel.org \
--cc=matttbe@kernel.org \
--cc=mptcp@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.