From: sashiko-bot@kernel.org
To: "Zhihao Cheng" <chengzhihao1@huawei.com>
Cc: linux-raid@vger.kernel.org, yukuai@fygo.io
Subject: Re: [PATCH 3/3] md/raid10: Don't free conf on raid10_run failure
Date: Mon, 21 Sep 2026 07:38:08 +0000 [thread overview]
Message-ID: <20260921073808.DE4C01F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260921071537.2902362-4-chengzhihao1@huawei.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] md/raid10: NULL ptr deref and I/O hang on raid10_run failure
--
commit 1bebf502d0ba7be4661dc272d82091e48c0924ff
Author: Zhihao Cheng <chengzhihao1@huawei.com>
md/raid10: Don't free conf on raid10_run failure
This patch prevents freeing the configuration on raid10_run() failure to
avoid a null pointer dereference later during shutdown. It modifies the
failure path to skip raid10_free_conf() and clearing mddev->private, leaving
the conf structure allocated.
> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> index 1093c798d9dde..9e4d4202f35cf 100644
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
[ ... ]
> @@ -4106,10 +4106,8 @@ static int raid10_run(struct mddev *mddev)
>
> return 0;
>
> -out_free_conf:
> +out_unregister_thread:
> md_unregister_thread(mddev, &mddev->thread);
> - raid10_free_conf(conf);
> - mddev->private = NULL;
[Severity: High]
Does leaving mddev->private allocated here expose the array to panics and
I/O hangs when raid10_run() fails?
Since the sysfs interface ignores personality run() failures:
drivers/md/md.c:level_store() {
...
pers->run(mddev);
...
}
The array remains pseudo-active. If subsequent I/O requests enter
raid10_make_request(), they can hang indefinitely because they attempt
to wake a NULL thread:
drivers/md/raid10.c:raid10_make_request() {
...
bio_list_add(&conf->pending_bio_list, mbio);
spin_unlock_irqrestore(&conf->device_lock, flags);
md_wakeup_thread(mddev->thread);
...
}
Furthermore, if a concurrent teardown or flush raises conf->barrier,
wait_barrier() will call stop_waiting_barrier(), which unconditionally
dereferences the NULL thread pointer, causing a panic:
drivers/md/raid10.c:stop_waiting_barrier() {
...
if (thread->tsk == current) {
...
}
> out:
> return ret;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260921071537.2902362-1-chengzhihao1@huawei.com?part=3
prev parent reply other threads:[~2026-09-21 7:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 7:15 [PATCH 0/3] md: Fix three raid5/raid10 bugs Zhihao Cheng
2026-09-21 7:15 ` [PATCH 1/3] md/raid5: Hide the origin mddev->thread before takeover Zhihao Cheng
2026-09-21 7:15 ` [PATCH 2/3] md/raid5: Don't free conf on raid5_run failure Zhihao Cheng
2026-09-21 7:15 ` [PATCH 3/3] md/raid10: Don't free conf on raid10_run failure Zhihao Cheng
2026-09-21 7:38 ` sashiko-bot [this message]
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=20260921073808.DE4C01F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=chengzhihao1@huawei.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