From: Mike Snitzer <snitzer@redhat.com>
To: Dan Ehrenberg <dehrenberg@chromium.org>
Cc: dm-devel@redhat.com, linux-kernel@vger.kernel.org,
agk@redhat.com, grundler@chromium.org, drewry@chromium.org,
gwendal@chromium.org
Subject: Re: [PATCH 2/2] dm: Get devices using name_to_dev_t
Date: Mon, 9 Feb 2015 16:14:08 -0500 [thread overview]
Message-ID: <20150209211407.GA2904@redhat.com> (raw)
In-Reply-To: <1422485157-33423-2-git-send-email-dehrenberg@chromium.org>
On Wed, Jan 28 2015 at 5:45pm -0500,
Dan Ehrenberg <dehrenberg@chromium.org> wrote:
> If a device is used as the root filesystem, it can't be built
> off of devices which are within the root filesystem (just like
> command line arguments to root=). For this reason, Linux has a
> pseudo-filesystem for root= and md initialization based on the
> function name_to_dev_t, which handles different ways of specifying
> devices including PARTUUID and major:minor.
>
> This patch applies name_to_dev_t to dm initialization. Rather
> than assuming that all things which are not major:minor are paths
> in an already-mounted filesystem, this patch first attempts
> to look up the device in the filesystem, and applies name_to_dev_t
> if it is not found there.
>
> In terms of backwards compatibility, there are some cases where
> behavior will be different:
> - If you have a file in the current working directory named 1:2 and
> you initialze DM there, then it will try to use that file rather
> than the disk with that major/minor pair as a backing device.
> - Similarly for other bdev types which name_to_dev_t knows how to
> interpret, the previous behavior was to repeatedly check for the
> existence of the file (e.g., while waiting for rootfs to come up)
> but the new behavior is to use the name_to_dev_t interpretation.
> For example, if you have a file named /dev/ubiblock0_0 which is
> a symlink to /dev/sda3, but it is not yet present when dm starts
> to initialize, then the name_to_dev_t interpretation will take
> precedence.
> I believe these incompatibilities would only show up in really
> strange setups with bad practices and we don't have to worry about
> them.
>
> Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
> ---
> drivers/md/dm-table.c | 20 ++++++++------------
> 1 file changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
> index 3afae9e..3ce1e01 100644
> --- a/drivers/md/dm-table.c
> +++ b/drivers/md/dm-table.c
> @@ -18,6 +18,7 @@
> #include <linux/mutex.h>
> #include <linux/delay.h>
> #include <linux/atomic.h>
> +#include <linux/mount.h>
>
> #define DM_MSG_PREFIX "table"
>
> @@ -372,23 +373,18 @@ int dm_get_device(struct dm_target *ti, const char *path, fmode_t mode,
> int r;
> dev_t uninitialized_var(dev);
> struct dm_dev_internal *dd;
> - unsigned int major, minor;
> struct dm_table *t = ti->table;
> - char dummy;
> + struct block_device *bdev;
>
> BUG_ON(!t);
>
> - if (sscanf(path, "%u:%u%c", &major, &minor, &dummy) == 2) {
> - /* Extract the major/minor numbers */
> - dev = MKDEV(major, minor);
> - if (MAJOR(dev) != major || MINOR(dev) != minor)
> - return -EOVERFLOW;
> + /* convert the path to a device */
> + bdev = lookup_bdev(path);
> + if (IS_ERR(bdev)) {
> + dev = name_to_dev_t(path);
> + if (!dev)
> + return -ENODEV;
> } else {
> - /* convert the path to a device */
> - struct block_device *bdev = lookup_bdev(path);
> -
> - if (IS_ERR(bdev))
> - return PTR_ERR(bdev);
> dev = bdev->bd_dev;
> bdput(bdev);
> }
name_to_dev_t isn't an exported symbol so it is undefined if DM is built
as a module (as many distros do).
I was going to pick this up to submit via linux-dm.git but lost
conviction once I hit compile errors and it became clear others need to
weigh in on the broader use of name_to_dev_t().
Please Cc Al Viro on v2 (and any others that are returned by
scripts/get_maintainer.pl).
Mike
prev parent reply other threads:[~2015-02-09 21:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-28 22:45 [PATCH 1/2] init: Stricter checking of major:minor root= values Dan Ehrenberg
2015-01-28 22:45 ` Dan Ehrenberg
2015-01-28 22:45 ` [PATCH 2/2] dm: Get devices using name_to_dev_t Dan Ehrenberg
2015-01-28 22:45 ` Dan Ehrenberg
2015-02-09 21:14 ` Mike Snitzer [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=20150209211407.GA2904@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=dehrenberg@chromium.org \
--cc=dm-devel@redhat.com \
--cc=drewry@chromium.org \
--cc=grundler@chromium.org \
--cc=gwendal@chromium.org \
--cc=linux-kernel@vger.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 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.