MPTCP Linux Development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: gregkh@linuxfoundation.org
Cc: mptcp@lists.linux.dev
Subject: Re: Patch "mptcp: annotate data-races around subflow->fully_established" has been added to the 6.12-stable tree
Date: Sun, 20 Sep 2026 07:48:55 +0000	[thread overview]
Message-ID: <20260920074855.D7DFF1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <2026092037-islamic-default-0aca@gregkh>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] mptcp: build failure due to READ_ONCE() on bit-field
--

commit 2cede4d0675228e6db5b209f56d2a298cf7cb2e9
Author: gregkh@linuxfoundation.org <gregkh@linuxfoundation.org>
Subject: Patch "mptcp: annotate data-races around subflow->fully_established" has been added to the 6.12-stable tree

This commit annotates data races around the fully_established flag in the
mptcp subflow context. It aims to convert the flag from a bit-field to a
boolean type to safely use READ_ONCE() and WRITE_ONCE().

Link: https://patch.msgid.link/20241021-net-next-mptcp-misc-6-13-v1-2-1ef02746504a@kernel.org

>     Additionally, we make a crucial change: convert the subflow's
>     'fully_established' from 'bit_field' to 'bool' type. This is
>     necessary because methods for avoiding data races don't work well
>     with 'bit_field'. Specifically, the 'READ_ONCE' needs to know
>     the size of the variable being accessed, which is not supported in
>     'bit_field'. Also, 'test_bit' expect the address of 'bit_field'.

[Severity: Low]
Was the hunk converting this field to a boolean dropped during the backport?
It appears fully_established is still defined as a bit-field in
struct mptcp_subflow_context.

Additionally, the write side update was missed in the backport:

net/mptcp/subflow.c:__mptcp_subflow_fully_established() {
    ...
	subflow->fully_established = 1;
    ...
}

This lacks the WRITE_ONCE() annotation and continues to perform an unsafe
read-modify-write on the shared bit-field word.

> diff --git a/net/mptcp/options.c b/net/mptcp/options.c
> index 370c3836b7712..1603b3702e220 100644
> --- a/net/mptcp/options.c
> +++ b/net/mptcp/options.c
> @@ -461,7 +461,7 @@ static bool mptcp_established_options_mp(struct sock *sk, struct sk_buff *skb,
>  		return false;
>  
>  	/* MPC/MPJ needed only on 3rd ack packet, DATA_FIN and TCP shutdown take precedence */
> -	if (subflow->fully_established || snd_data_fin_enable ||
> +	if (READ_ONCE(subflow->fully_established) || snd_data_fin_enable ||

[Severity: Low]
Does this trigger a compiler error? Since the struct modification was missed
and fully_established remains a bit-field, applying READ_ONCE() here attempts
to take the address of a bit-field, which is syntactically invalid in C.

[ ... ]

> diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
> index 568a72702b080..e9dba0708ee70 100644
> --- a/net/mptcp/protocol.h
> +++ b/net/mptcp/protocol.h
> @@ -532,7 +532,7 @@ struct mptcp_subflow_context {
>  		is_mptfo : 1,	    /* subflow is doing TFO */
>  		close_event_done : 1,       /* has done the post-closed part */
>  		mpc_drop : 1,	    /* the MPC option has been dropped in a rtx */
> -		__unused : 8;
> +		__unused : 9;

[Severity: Low]
Does this increase the total bit-field group to 33 bits, causing a boundary
overflow? 

Since fully_established wasn't actually removed from the bit-field group in
this backport, incrementing the unused bits to 9 pushes the total beyond a
32-bit word size.

>  	bool	data_avail;
>  	bool	scheduled;
>  	bool	pm_listener;	    /* a listener managed by the kernel PM? */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/2026092037-islamic-default-0aca@gregkh?part=1

  reply	other threads:[~2026-09-20  7:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-19 19:56 [PATCH 6.12.y 0/5] mptcp: fix recent failed backports (20260919) Matthieu Baerts (NGI0)
2026-09-19 19:56 ` [PATCH 6.12.y 1/5] mptcp: annotate data-races around subflow->fully_established Matthieu Baerts (NGI0)
2026-09-20  7:36   ` Patch "mptcp: annotate data-races around subflow->fully_established" has been added to the 6.12-stable tree gregkh
2026-09-20  7:48     ` sashiko-bot [this message]
2026-09-20  9:33       ` Matthieu Baerts
2026-09-20 13:10         ` Greg KH
2026-09-20 13:23           ` Matthieu Baerts
2026-09-19 19:56 ` [PATCH 6.12.y 2/5] mptcp: remove unneeded READ_ONCE() annotation Matthieu Baerts (NGI0)
2026-09-19 19:56 ` [PATCH 6.12.y 3/5] mptcp: avoid unneeded actions on subflow reset Matthieu Baerts (NGI0)
2026-09-20  7:36   ` Patch "mptcp: avoid unneeded actions on subflow reset" has been added to the 6.12-stable tree gregkh
2026-09-19 19:56 ` [PATCH 6.12.y 4/5] mptcp: close race between scheduler and state change Matthieu Baerts (NGI0)
2026-09-20  7:36   ` Patch "mptcp: close race between scheduler and state change" has been added to the 6.12-stable tree gregkh
2026-09-19 19:56 ` [PATCH 6.12.y 5/5] mptcp: fix bad accounting in __mptcp_subflow_push_pending() Matthieu Baerts (NGI0)
2026-09-20  7:36   ` Patch "mptcp: fix bad accounting in __mptcp_subflow_push_pending()" has been added to the 6.12-stable tree gregkh

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=20260920074855.D7DFF1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=gregkh@linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox