From: Mike Snitzer <snitzer@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: stable@vger.kernel.org, Jan Kara <jack@suse.cz>,
Ira Weiny <ira.weiny@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
Keith Busch <keith.busch@intel.com>,
Matthew Wilcox <willy@infradead.org>,
Vishal Verma <vishal.l.verma@intel.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Pankaj Gupta <pagupta@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-nvdimm@lists.01.org,
dm-devel@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: dax: Arrange for dax_supported check to span multiple devices
Date: Thu, 16 May 2019 14:57:32 -0400 [thread overview]
Message-ID: <20190516185732.GA27796@redhat.com> (raw)
In-Reply-To: <155789172402.748145.11853718580748830476.stgit@dwillia2-desk3.amr.corp.intel.com>
On Tue, May 14 2019 at 11:48pm -0400,
Dan Williams <dan.j.williams@intel.com> wrote:
> Pankaj reports that starting with commit ad428cdb525a "dax: Check the
> end of the block-device capacity with dax_direct_access()" device-mapper
> no longer allows dax operation. This results from the stricter checks in
> __bdev_dax_supported() that validate that the start and end of a
> block-device map to the same 'pagemap' instance.
>
> Teach the dax-core and device-mapper to validate the 'pagemap' on a
> per-target basis. This is accomplished by refactoring the
> bdev_dax_supported() internals into generic_fsdax_supported() which
> takes a sector range to validate. Consequently generic_fsdax_supported()
> is suitable to be used in a device-mapper ->iterate_devices() callback.
> A new ->dax_supported() operation is added to allow composite devices to
> split and route upper-level bdev_dax_supported() requests.
>
> Fixes: ad428cdb525a ("dax: Check the end of the block-device...")
> Cc: <stable@vger.kernel.org>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Ira Weiny <ira.weiny@intel.com>
> Cc: Dave Jiang <dave.jiang@intel.com>
> Cc: Mike Snitzer <snitzer@redhat.com>
> Cc: Keith Busch <keith.busch@intel.com>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Vishal Verma <vishal.l.verma@intel.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Reported-by: Pankaj Gupta <pagupta@redhat.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> Hi Mike,
>
> Another day another new dax operation to allow device-mapper to better
> scope dax operations.
>
> Let me know if the device-mapper changes look sane. This passes a new
> unit test that indeed fails on current mainline.
>
> https://github.com/pmem/ndctl/blob/device-mapper-pending/test/dm.sh
>
> drivers/dax/super.c | 88 +++++++++++++++++++++++++++---------------
> drivers/md/dm-table.c | 17 +++++---
> drivers/md/dm.c | 20 ++++++++++
> drivers/md/dm.h | 1
> drivers/nvdimm/pmem.c | 1
> drivers/s390/block/dcssblk.c | 1
> include/linux/dax.h | 19 +++++++++
> 7 files changed, 110 insertions(+), 37 deletions(-)
>
...
> diff --git a/drivers/md/dm.h b/drivers/md/dm.h
> index 2d539b82ec08..e5e240bfa2d0 100644
> --- a/drivers/md/dm.h
> +++ b/drivers/md/dm.h
> @@ -78,6 +78,7 @@ void dm_unlock_md_type(struct mapped_device *md);
> void dm_set_md_type(struct mapped_device *md, enum dm_queue_mode type);
> enum dm_queue_mode dm_get_md_type(struct mapped_device *md);
> struct target_type *dm_get_immutable_target_type(struct mapped_device *md);
> +bool dm_table_supports_dax(struct dm_table *t, int blocksize);
>
> int dm_setup_md_queue(struct mapped_device *md, struct dm_table *t);
>
I'd prefer to have dm_table_supports_dax come just after
dm_table_get_md_mempools in the preceding dm_table section of dm.h (just
above this mapped_device section you extended).
But other than that nit, patch looks great on a DM level:
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
WARNING: multiple messages have this Message-ID (diff)
From: Mike Snitzer <snitzer@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Jan Kara <jack@suse.cz>,
linux-nvdimm@lists.01.org,
Heiko Carstens <heiko.carstens@de.ibm.com>,
linux-kernel@vger.kernel.org,
Matthew Wilcox <willy@infradead.org>,
linux-fsdevel@vger.kernel.org, dm-devel@redhat.com,
stable@vger.kernel.org,
Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: dax: Arrange for dax_supported check to span multiple devices
Date: Thu, 16 May 2019 14:57:32 -0400 [thread overview]
Message-ID: <20190516185732.GA27796@redhat.com> (raw)
In-Reply-To: <155789172402.748145.11853718580748830476.stgit@dwillia2-desk3.amr.corp.intel.com>
On Tue, May 14 2019 at 11:48pm -0400,
Dan Williams <dan.j.williams@intel.com> wrote:
> Pankaj reports that starting with commit ad428cdb525a "dax: Check the
> end of the block-device capacity with dax_direct_access()" device-mapper
> no longer allows dax operation. This results from the stricter checks in
> __bdev_dax_supported() that validate that the start and end of a
> block-device map to the same 'pagemap' instance.
>
> Teach the dax-core and device-mapper to validate the 'pagemap' on a
> per-target basis. This is accomplished by refactoring the
> bdev_dax_supported() internals into generic_fsdax_supported() which
> takes a sector range to validate. Consequently generic_fsdax_supported()
> is suitable to be used in a device-mapper ->iterate_devices() callback.
> A new ->dax_supported() operation is added to allow composite devices to
> split and route upper-level bdev_dax_supported() requests.
>
> Fixes: ad428cdb525a ("dax: Check the end of the block-device...")
> Cc: <stable@vger.kernel.org>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Ira Weiny <ira.weiny@intel.com>
> Cc: Dave Jiang <dave.jiang@intel.com>
> Cc: Mike Snitzer <snitzer@redhat.com>
> Cc: Keith Busch <keith.busch@intel.com>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Vishal Verma <vishal.l.verma@intel.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Reported-by: Pankaj Gupta <pagupta@redhat.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> Hi Mike,
>
> Another day another new dax operation to allow device-mapper to better
> scope dax operations.
>
> Let me know if the device-mapper changes look sane. This passes a new
> unit test that indeed fails on current mainline.
>
> https://github.com/pmem/ndctl/blob/device-mapper-pending/test/dm.sh
>
> drivers/dax/super.c | 88 +++++++++++++++++++++++++++---------------
> drivers/md/dm-table.c | 17 +++++---
> drivers/md/dm.c | 20 ++++++++++
> drivers/md/dm.h | 1
> drivers/nvdimm/pmem.c | 1
> drivers/s390/block/dcssblk.c | 1
> include/linux/dax.h | 19 +++++++++
> 7 files changed, 110 insertions(+), 37 deletions(-)
>
...
> diff --git a/drivers/md/dm.h b/drivers/md/dm.h
> index 2d539b82ec08..e5e240bfa2d0 100644
> --- a/drivers/md/dm.h
> +++ b/drivers/md/dm.h
> @@ -78,6 +78,7 @@ void dm_unlock_md_type(struct mapped_device *md);
> void dm_set_md_type(struct mapped_device *md, enum dm_queue_mode type);
> enum dm_queue_mode dm_get_md_type(struct mapped_device *md);
> struct target_type *dm_get_immutable_target_type(struct mapped_device *md);
> +bool dm_table_supports_dax(struct dm_table *t, int blocksize);
>
> int dm_setup_md_queue(struct mapped_device *md, struct dm_table *t);
>
I'd prefer to have dm_table_supports_dax come just after
dm_table_get_md_mempools in the preceding dm_table section of dm.h (just
above this mapped_device section you extended).
But other than that nit, patch looks great on a DM level:
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
next prev parent reply other threads:[~2019-05-16 18:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-15 3:48 [PATCH] dax: Arrange for dax_supported check to span multiple devices Dan Williams
2019-05-15 3:48 ` Dan Williams
2019-05-15 3:48 ` Dan Williams
2019-05-15 7:30 ` Jan Kara
2019-05-15 7:30 ` Jan Kara
2019-05-15 8:38 ` Pankaj Gupta
2019-05-15 8:38 ` Pankaj Gupta
2019-05-16 18:57 ` Mike Snitzer [this message]
2019-05-16 18:57 ` Mike Snitzer
2019-05-16 21:10 ` Dan Williams
2019-05-16 21:10 ` Dan Williams
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=20190516185732.GA27796@redhat.com \
--to=snitzer@redhat.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dm-devel@redhat.com \
--cc=heiko.carstens@de.ibm.com \
--cc=ira.weiny@intel.com \
--cc=jack@suse.cz \
--cc=keith.busch@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=pagupta@redhat.com \
--cc=schwidefsky@de.ibm.com \
--cc=stable@vger.kernel.org \
--cc=vishal.l.verma@intel.com \
--cc=willy@infradead.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.