linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Xiao Ni <xni@redhat.com>
To: NeilBrown <neilb@suse.de>
Cc: Jes Sorensen <jes@trained-monkey.org>,
	Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>,
	Song Liu <song@kernel.org>,
	Linux regressions mailing list <regressions@lists.linux.dev>,
	linux-raid <linux-raid@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Nikolay Kichukov <hijacker@oldum.net>
Subject: Re: [PATCH - mdadm] mdopen: always try create_named_array()
Date: Wed, 22 Mar 2023 11:00:18 +0800	[thread overview]
Message-ID: <CALTww2916uiO8_ViJQXutO2BPasFmiUJtfz8MxW0HKjDzwGFeQ@mail.gmail.com> (raw)
In-Reply-To: <167875238571.8008.9808655454439667586@noble.neil.brown.name>

On Tue, Mar 14, 2023 at 8:08 AM NeilBrown <neilb@suse.de> wrote:
>
>
> mdopen() will use create_named_array() to ask the kernel to create the
> given md array, but only if it is given a number or name.
> If it is NOT given a name and is required to choose one itself using
> find_free_devnm() it does NOT use create_named_array().
>
> On kernels with CONFIG_BLOCK_LEGACY_AUTOLOAD not set, this can result in
> failure to assemble an array.  This can particularly seen when the
> "name" of the array begins with a host name different to the name of the
> host running the command.
>
> So add the missing call to create_named_array().
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217074

Hi Neil

I have two questions, hope you can help to understand the function
create_mddev better.

Frist, from the comment7 of the bug you mentioned:

There are two different sorts names.  Note that you almost
acknowledged this by writing "name for my md device node" while the
documentation only talks about names for "md devices", not for "md
device nodes".

There are
1/ there are names in /dev or /dev/md/ (device nodes)
2/ there are names that appear in /proc/mdstat and in /sys/block/ (devices)

Thanks for the clarification. But it looks like it doesn't work like
what you said.
For example:
mdadm -CR /dev/md/root -l0 -n2 /dev/sda /dev/sdc --name=test
cat /proc/mdstat
Personalities : [raid0]
md127 : active raid0 sdc[1] sda[0]
      3906764800 blocks super 1.2 512k chunks
cd /sys/block/md127/md/

In /proc/mdstat and /sys/block, they all use md127 rather than the name(root)

Before this patch,  it creates a symbol link with the name root rather than test
ll /dev/md/root
lrwxrwxrwx. 1 root root 8 Mar 21 22:35 /dev/md/root -> ../md127

So "test" which is specified by --name looks like it has little usage.

By the way, after this patch, the symbol link /dev/md/root can't be
created anymore.
Is it a regression problem?

Second, are there possibilities that the arguments "dev" and "name" of
function create_mddev
are null at the same time?
After some tests, I found dev can't be null when creating a raid
device. It can be checked before
calling create_mddev. And we must get a name after creating a raid
device. So when assembling
a raid device, the name must not be null. So the dev and name can't be
null at the same time, right?

Best Regards
Xiao


> Signed-off-by: NeilBrown <neilb@suse.de>
> ---
>  mdopen.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/mdopen.c b/mdopen.c
> index d18c931996d2..810f79a3d19a 100644
> --- a/mdopen.c
> +++ b/mdopen.c
> @@ -370,6 +370,7 @@ int create_mddev(char *dev, char *name, int autof, int trustworthy,
>                 }
>                 if (block_udev)
>                         udev_block(devnm);
> +               create_named_array(devnm);
>         }
>
>         sprintf(devname, "/dev/%s", devnm);
> --
> 2.39.2
>


  parent reply	other threads:[~2023-03-22  3:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-14  0:06 [PATCH - mdadm] mdopen: always try create_named_array() NeilBrown
2023-03-14  9:11 ` Mariusz Tkaczyk
2023-03-19 16:36 ` Jes Sorensen
2023-03-19 22:09   ` NeilBrown
2023-03-20 17:15     ` Jes Sorensen
2023-03-21  8:49       ` Mariusz Tkaczyk
2023-03-22  3:00 ` Xiao Ni [this message]
2023-03-22  3:24   ` NeilBrown
2023-03-22  6:51     ` Mariusz Tkaczyk
2023-03-23  2:09     ` Xiao Ni
2023-03-29 21:51     ` NeilBrown
2023-03-30  0:10       ` Xiao Ni
2023-03-30  3:15         ` NeilBrown
2023-03-30  4:55           ` Xiao Ni

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=CALTww2916uiO8_ViJQXutO2BPasFmiUJtfz8MxW0HKjDzwGFeQ@mail.gmail.com \
    --to=xni@redhat.com \
    --cc=hijacker@oldum.net \
    --cc=jes@trained-monkey.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=mariusz.tkaczyk@linux.intel.com \
    --cc=neilb@suse.de \
    --cc=regressions@lists.linux.dev \
    --cc=song@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).