From: Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org
Subject: Re: [PATCH 4/7] dm: prevent DAX mounts if not supported
Date: Fri, 25 May 2018 15:54:10 -0400 [thread overview]
Message-ID: <20180525195410.GA11008@redhat.com> (raw)
In-Reply-To: <20180525025518.11405-5-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On Thu, May 24 2018 at 10:55pm -0400,
Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
> Currently the code in dm_dax_direct_access() only checks whether the target
> type has a direct_access() operation defined, not whether the underlying
> block devices all support DAX. This latter property can be seen by looking
> at whether we set the QUEUE_FLAG_DAX request queue flag when creating the
> DM device.
>
> This is problematic if we have, for example, a dm-linear device made up of
> a PMEM namespace in fsdax mode followed by a ramdisk from BRD.
> QUEUE_FLAG_DAX won't be set on the dm-linear device's request queue, but
> we have a working direct_access() entry point and the first member of the
> dm-linear set *does* support DAX.
>
> This allows the user to create a filesystem on the dm-linear device, and
> then mount it with DAX. The filesystem's bdev_dax_supported() test will
> pass because it'll operate on the first member of the dm-linear device,
> which happens to be a fsdax PMEM namespace.
>
> All DAX I/O will then fail to that dm-linear device because the lack of
> QUEUE_FLAG_DAX prevents fs_dax_get_by_bdev() from working. This means that
> the struct dax_device isn't ever set in the filesystem, so
> dax_direct_access() will always return -EOPNOTSUPP.
>
> By failing out of dm_dax_direct_access() if QUEUE_FLAG_DAX isn't set we let
> the filesystem know we don't support DAX at mount time. The filesystem
> will then silently fall back and remove the dax mount option, causing it to
> work properly.
>
> Signed-off-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Fixes: commit 545ed20e6df6 ("dm: add infrastructure for DAX support")
> ---
> drivers/md/dm.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/md/dm.c b/drivers/md/dm.c
> index 0a7b0107ca78..9728433362d1 100644
> --- a/drivers/md/dm.c
> +++ b/drivers/md/dm.c
> @@ -1050,14 +1050,13 @@ static long dm_dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff,
>
> if (!ti)
> goto out;
> - if (!ti->type->direct_access)
> + if (!blk_queue_dax(md->queue))
> goto out;
> len = max_io_len(sector, ti) / PAGE_SECTORS;
> if (len < 1)
> goto out;
> nr_pages = min(len, nr_pages);
> - if (ti->type->direct_access)
> - ret = ti->type->direct_access(ti, pgoff, nr_pages, kaddr, pfn);
> + ret = ti->type->direct_access(ti, pgoff, nr_pages, kaddr, pfn);
So I followed all the rationale for this patch. But the last change
doesn't make any sense. We should still verify that the target has
ti->type->direct_access before calling it. So please reinstate that
check before calling it.
Thanks,
Mike
WARNING: multiple messages have this Message-ID (diff)
From: Mike Snitzer <snitzer@redhat.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: linux-fsdevel@vger.kernel.org, dm-devel@redhat.com,
linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org
Subject: Re: [PATCH 4/7] dm: prevent DAX mounts if not supported
Date: Fri, 25 May 2018 15:54:10 -0400 [thread overview]
Message-ID: <20180525195410.GA11008@redhat.com> (raw)
In-Reply-To: <20180525025518.11405-5-ross.zwisler@linux.intel.com>
On Thu, May 24 2018 at 10:55pm -0400,
Ross Zwisler <ross.zwisler@linux.intel.com> wrote:
> Currently the code in dm_dax_direct_access() only checks whether the target
> type has a direct_access() operation defined, not whether the underlying
> block devices all support DAX. This latter property can be seen by looking
> at whether we set the QUEUE_FLAG_DAX request queue flag when creating the
> DM device.
>
> This is problematic if we have, for example, a dm-linear device made up of
> a PMEM namespace in fsdax mode followed by a ramdisk from BRD.
> QUEUE_FLAG_DAX won't be set on the dm-linear device's request queue, but
> we have a working direct_access() entry point and the first member of the
> dm-linear set *does* support DAX.
>
> This allows the user to create a filesystem on the dm-linear device, and
> then mount it with DAX. The filesystem's bdev_dax_supported() test will
> pass because it'll operate on the first member of the dm-linear device,
> which happens to be a fsdax PMEM namespace.
>
> All DAX I/O will then fail to that dm-linear device because the lack of
> QUEUE_FLAG_DAX prevents fs_dax_get_by_bdev() from working. This means that
> the struct dax_device isn't ever set in the filesystem, so
> dax_direct_access() will always return -EOPNOTSUPP.
>
> By failing out of dm_dax_direct_access() if QUEUE_FLAG_DAX isn't set we let
> the filesystem know we don't support DAX at mount time. The filesystem
> will then silently fall back and remove the dax mount option, causing it to
> work properly.
>
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> Fixes: commit 545ed20e6df6 ("dm: add infrastructure for DAX support")
> ---
> drivers/md/dm.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/md/dm.c b/drivers/md/dm.c
> index 0a7b0107ca78..9728433362d1 100644
> --- a/drivers/md/dm.c
> +++ b/drivers/md/dm.c
> @@ -1050,14 +1050,13 @@ static long dm_dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff,
>
> if (!ti)
> goto out;
> - if (!ti->type->direct_access)
> + if (!blk_queue_dax(md->queue))
> goto out;
> len = max_io_len(sector, ti) / PAGE_SECTORS;
> if (len < 1)
> goto out;
> nr_pages = min(len, nr_pages);
> - if (ti->type->direct_access)
> - ret = ti->type->direct_access(ti, pgoff, nr_pages, kaddr, pfn);
> + ret = ti->type->direct_access(ti, pgoff, nr_pages, kaddr, pfn);
So I followed all the rationale for this patch. But the last change
doesn't make any sense. We should still verify that the target has
ti->type->direct_access before calling it. So please reinstate that
check before calling it.
Thanks,
Mike
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Mike Snitzer <snitzer@redhat.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Toshi Kani <toshi.kani@hpe.com>,
dm-devel@redhat.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org
Subject: Re: [PATCH 4/7] dm: prevent DAX mounts if not supported
Date: Fri, 25 May 2018 15:54:10 -0400 [thread overview]
Message-ID: <20180525195410.GA11008@redhat.com> (raw)
In-Reply-To: <20180525025518.11405-5-ross.zwisler@linux.intel.com>
On Thu, May 24 2018 at 10:55pm -0400,
Ross Zwisler <ross.zwisler@linux.intel.com> wrote:
> Currently the code in dm_dax_direct_access() only checks whether the target
> type has a direct_access() operation defined, not whether the underlying
> block devices all support DAX. This latter property can be seen by looking
> at whether we set the QUEUE_FLAG_DAX request queue flag when creating the
> DM device.
>
> This is problematic if we have, for example, a dm-linear device made up of
> a PMEM namespace in fsdax mode followed by a ramdisk from BRD.
> QUEUE_FLAG_DAX won't be set on the dm-linear device's request queue, but
> we have a working direct_access() entry point and the first member of the
> dm-linear set *does* support DAX.
>
> This allows the user to create a filesystem on the dm-linear device, and
> then mount it with DAX. The filesystem's bdev_dax_supported() test will
> pass because it'll operate on the first member of the dm-linear device,
> which happens to be a fsdax PMEM namespace.
>
> All DAX I/O will then fail to that dm-linear device because the lack of
> QUEUE_FLAG_DAX prevents fs_dax_get_by_bdev() from working. This means that
> the struct dax_device isn't ever set in the filesystem, so
> dax_direct_access() will always return -EOPNOTSUPP.
>
> By failing out of dm_dax_direct_access() if QUEUE_FLAG_DAX isn't set we let
> the filesystem know we don't support DAX at mount time. The filesystem
> will then silently fall back and remove the dax mount option, causing it to
> work properly.
>
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> Fixes: commit 545ed20e6df6 ("dm: add infrastructure for DAX support")
> ---
> drivers/md/dm.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/md/dm.c b/drivers/md/dm.c
> index 0a7b0107ca78..9728433362d1 100644
> --- a/drivers/md/dm.c
> +++ b/drivers/md/dm.c
> @@ -1050,14 +1050,13 @@ static long dm_dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff,
>
> if (!ti)
> goto out;
> - if (!ti->type->direct_access)
> + if (!blk_queue_dax(md->queue))
> goto out;
> len = max_io_len(sector, ti) / PAGE_SECTORS;
> if (len < 1)
> goto out;
> nr_pages = min(len, nr_pages);
> - if (ti->type->direct_access)
> - ret = ti->type->direct_access(ti, pgoff, nr_pages, kaddr, pfn);
> + ret = ti->type->direct_access(ti, pgoff, nr_pages, kaddr, pfn);
So I followed all the rationale for this patch. But the last change
doesn't make any sense. We should still verify that the target has
ti->type->direct_access before calling it. So please reinstate that
check before calling it.
Thanks,
Mike
next prev parent reply other threads:[~2018-05-25 19:54 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-25 2:55 [PATCH 0/7] Fix DM DAX handling Ross Zwisler
2018-05-25 2:55 ` Ross Zwisler
2018-05-25 2:55 ` Ross Zwisler
[not found] ` <20180525025518.11405-1-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-05-25 2:55 ` [PATCH 1/7] fs: allow per-device dax status checking for filesystems Ross Zwisler
2018-05-25 2:55 ` Ross Zwisler
2018-05-25 2:55 ` Ross Zwisler
[not found] ` <20180525025518.11405-2-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-05-25 5:02 ` Darrick J. Wong
2018-05-25 5:02 ` Darrick J. Wong
2018-05-25 5:02 ` Darrick J. Wong
2018-05-25 15:42 ` Ross Zwisler
2018-05-25 15:42 ` Ross Zwisler
[not found] ` <20180525154229.GA11044-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-05-25 19:23 ` Darrick J. Wong
2018-05-25 19:23 ` Darrick J. Wong
2018-05-25 19:23 ` Darrick J. Wong
2018-05-26 14:07 ` kbuild test robot
2018-05-26 14:07 ` kbuild test robot
2018-05-26 14:07 ` kbuild test robot
2018-05-25 2:55 ` [PATCH 2/7] dax: change bdev_dax_supported() to support boolean returns Ross Zwisler
2018-05-25 2:55 ` Ross Zwisler
2018-05-25 2:55 ` Ross Zwisler
[not found] ` <20180525025518.11405-3-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-05-25 5:01 ` Darrick J. Wong
2018-05-25 5:01 ` Darrick J. Wong
2018-05-25 5:01 ` Darrick J. Wong
2018-05-25 2:55 ` [PATCH 3/7] dm: fix test for DAX device support Ross Zwisler
2018-05-25 2:55 ` Ross Zwisler
2018-05-25 2:55 ` Ross Zwisler
2018-05-25 2:55 ` [PATCH 4/7] dm: prevent DAX mounts if not supported Ross Zwisler
2018-05-25 2:55 ` Ross Zwisler
2018-05-25 2:55 ` Ross Zwisler
[not found] ` <20180525025518.11405-5-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-05-25 19:54 ` Mike Snitzer [this message]
2018-05-25 19:54 ` Mike Snitzer
2018-05-25 19:54 ` Mike Snitzer
[not found] ` <20180525195410.GA11008-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-05-25 21:36 ` Ross Zwisler
2018-05-25 21:36 ` Ross Zwisler
2018-05-25 21:36 ` Ross Zwisler
2018-05-25 2:55 ` [PATCH 5/7] dm: remove DM_TYPE_DAX_BIO_BASED dm_queue_mode Ross Zwisler
2018-05-25 2:55 ` Ross Zwisler
2018-05-25 2:55 ` Ross Zwisler
2018-05-25 2:55 ` [PATCH 6/7] dm-snap: remove unnecessary direct_access() stub Ross Zwisler
2018-05-25 2:55 ` Ross Zwisler
2018-05-25 2:55 ` Ross Zwisler
2018-05-25 2:55 ` [PATCH 7/7] dm-error: " Ross Zwisler
2018-05-25 2:55 ` Ross Zwisler
2018-05-25 2:55 ` Ross Zwisler
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=20180525195410.GA11008@redhat.com \
--to=snitzer-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org \
--cc=ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.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.