From: "Masalkhi, Abd Alrhman" <abd.masalkhi@gatech.edu>
To: "sashiko-reviews@lists.linux.dev" <sashiko-reviews@lists.linux.dev>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
"yukuai@fygo.io" <yukuai@fygo.io>
Subject: Re: [RFC PATCH v2 4/4] md: add a control device for array management
Date: Wed, 7 Oct 2026 10:41:49 +0000 [thread overview]
Message-ID: <m2jyntbxn8.fsf@gmail.com> (raw)
In-Reply-To: <20261001131958.E1E6C1F000FF@smtp.kernel.org>
Hi Kuai,
On Thu, Oct 01, 2026 at 13:19 +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issu=(s) to consider:
> - [High] md: MD_CLOSING flag is not cleared on error or RO transition
> - [Medium] md: strict boundary check on UAPI name field rejects valid
> inputs
I will fix those in v3.
> --
>
> commit c2d6351bf75bbe25a5734b17638d14317134886c
> Author: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
>
> md: add a control device for array management
>
> This commit introduces a new misc character device, /dev/md-control, to h=ndle
> md management ioctls without requiring an open file descriptor to the md =lock
> device itself. This prevents races during array stop and reconfiguration =hen
> multiple tasks share the same file descriptor table. The existing block d=vice
> ioctls are preserved for compatibility but trigger a warning recommending=n
> upgrade to mdadm.
>
>> diff --git a/drivers/md/md.c b/drivers/md/md.c
>> --- a/drivers/md/md.c
>> +++ b/drivers/md/md.c
> [ ... ]
>> @@ -8602,6 +8608,623 @@ static int md_compat_ioctl(struct block_device *=dev, blk_mode_t mode,
> [ ... ]
>> +static struct mddev *mdctl_get_mddev_name(const char *name)
>> +{
>> + unsigned long minor;
>> + struct mddev *mddev, *ret = ERR_PTR(-EINVAL);
>> +
>> + if (strncmp(name, "md", 2) || name[MD_NAME_LEN - 1])
>> + return ret;
>
> [Severity: Medium]
> Will this strict boundary check reject valid user input? If a userspace
> program populates the name field with a short, properly null-terminated
> string but leaves the trailing padding bytes uninitialized on the stack,
> this check will fail because the absolute last byte isn't zero. Could
> this be relaxed to ensure the string is null-terminated anywhere within
> the buffer instead?
>
> [ ... ]
>> +static long mdctl_ioctl(struct file *filp, uint cmd, ulong u)
>> +{
> [ ... ]
>> + if (cmd == MD_STOP_ARRAY) {
>> + /* Need to flush page cache, and ensure no openers */
>> + err = mddev_set_closing_and_sync_blockdev(mddev, 0);
>> + if (err)
>> + goto out;
>> + }
> [ ... ]
>> +out:
>> + mddev_put(mddev);
>> + return err;
>> +}
>
> [Severity: High]
> Does this exit path need to clear the MD_CLOSING flag if it was set
> earlier? When a privileged user calls MD_STOP_ARRAY and the array is
> busy or transitions to read-only, MD_CLOSING is successfully set, but
> the ioctl may later jump to out or return an error. Since the flag is
> never cleared on these paths in mdctl_ioctl(), would this leave the
> block device permanently locked out from future opens until reboot?
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20261001125611.94=731-1-abd.masalkhi@gmail.com?part=4
--
Best Regards,
Abd-Alrhman
prev parent reply other threads:[~2026-10-07 10:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 12:56 [RFC PATCH v2 0/4] md: add a control device for array management Abd-Alrhman Masalkhi
2026-10-01 12:56 ` [RFC PATCH v2 1/4] md: add uapi definitions for the md control device Abd-Alrhman Masalkhi
2026-10-01 12:56 ` [RFC PATCH v2 2/4] md: pass struct mdu_disk_info64 to md_add_new_disk() Abd-Alrhman Masalkhi
2026-10-01 12:56 ` [RFC PATCH v2 3/4] md: use struct mdu_array_info64 for SET_ARRAY_INFO Abd-Alrhman Masalkhi
2026-10-01 12:56 ` [RFC PATCH v2 4/4] md: add a control device for array management Abd-Alrhman Masalkhi
2026-10-01 13:19 ` sashiko-bot
2026-10-07 10:41 ` Masalkhi, Abd Alrhman [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=m2jyntbxn8.fsf@gmail.com \
--to=abd.masalkhi@gatech.edu \
--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 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.