Linux RAID subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Chen Cheng" <chencheng@fnnas.com>
Cc: yukuai@fygo.io, linux-raid@vger.kernel.org
Subject: Re: [PATCH v2] md: use READ_ONCE() for lockless reads of sb_flags
Date: Tue, 23 Jun 2026 11:25:31 +0000	[thread overview]
Message-ID: <20260623112532.4D4761F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260623111617.2500313-1-chencheng@fnnas.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Low] Lockless plain reads of `mddev->recovery` will cause KCSAN data race warnings, similar to the ones fixed for `sb_flags`.
--

commit f286787fa23a14cb6ec022eb99574f7a85f9957d
Author: Chen Cheng <chencheng@fnnas.com>

md: use READ_ONCE() for lockless reads of sb_flags

This patch adds READ_ONCE() annotations to lockless reads of mddev->sb_flags
across md, raid1, raid5, and raid10. It aims to fix KCSAN data race warnings
caused by concurrent set_bit() operations on sb_flags.

> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 096bb64e87bd5..c5c50640b6849 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -6832,7 +6832,7 @@ int md_run(struct mddev *mddev)
>  		set_bit(MD_RECOVERY_RECOVER, &mddev->recovery);
>  	set_bit(MD_RECOVERY_NEEDED, &mddev->recovery);

[Severity: Low]
This is a pre-existing issue, but since this patch targets KCSAN warnings for
atomic bitmasks, could plain lockless reads of mddev->recovery trigger similar
data races?

There are places where mddev->recovery is read without locks and without
READ_ONCE(), potentially causing KCSAN noise against set_bit() updates:

drivers/md/md.c:md_sync_action() {
    ...
    unsigned long recovery = mddev->recovery;
    ...
}

drivers/md/md.c:set_bitmap_file() {
    ...
    if (mddev->recovery || mddev->sync_thread)
    ...
}

drivers/md/md.c:update_array_info() {
    ...
    if (mddev->recovery || mddev->sync_thread) {
    ...
}

Should READ_ONCE() also be applied to these reads of mddev->recovery to
provide a more complete fix?

> -	if (mddev->sb_flags)
> +	if (READ_ONCE(mddev->sb_flags))
>  		md_update_sb(mddev, 0);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260623111617.2500313-1-chencheng@fnnas.com?part=1

  reply	other threads:[~2026-06-23 11:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-23 11:16 [PATCH v2] md: use READ_ONCE() for lockless reads of sb_flags Chen Cheng
2026-06-23 11:25 ` sashiko-bot [this message]
2026-06-23 12:51   ` Chen Cheng

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=20260623112532.4D4761F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=chencheng@fnnas.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yukuai@fygo.io \
    /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