[PATCH v3 0/4] Support DAX for device-mapper linear devices

[PATCH v3 0/4] Support DAX for device-mapper linear devices

[Mike Snitzer]

Jens, please pick up the first 2 block patches and I'll get the other
2 DM patches staged for 4.8.

v3:
 - fixed "warning: context imbalance in 'dm_blk_direct_access' -
   different lock contexts for basic block" due to missing
   dm_put_live_table in dm_blk_direct_access's dm_get_live_table error
   path
 - refactored dm-table.c code to centralize checking if all devices in
   a DM table support DAX (removed need for target to set
   ->dax_supported)
 - included Yigal Korman's patch to add 'dax' sysfs attribute

Toshi Kani (3):
  block: add QUEUE_FLAG_DAX for devices to advertise their DAX support
  dm: add infrastructure for DAX support
  dm linear: add DAX support

Yigal Korman (1):
  block: expose QUEUE_FLAG_DAX in sysfs

 block/blk-sysfs.c             | 11 +++++++++++
 drivers/block/brd.c           |  4 +++-
 drivers/md/dm-linear.c        | 21 ++++++++++++++++++++-
 drivers/md/dm-table.c         | 44 ++++++++++++++++++++++++++++++++++++++++++-
 drivers/md/dm.c               | 38 +++++++++++++++++++++++++++++++++++--
 drivers/md/dm.h               |  1 +
 drivers/nvdimm/pmem.c         |  1 +
 drivers/s390/block/dcssblk.c  |  1 +
 fs/block_dev.c                |  5 +++--
 include/linux/blkdev.h        |  2 ++
 include/linux/device-mapper.h | 10 ++++++++++
 include/uapi/linux/dm-ioctl.h |  4 ++--
 12 files changed, 133 insertions(+), 9 deletions(-)

-- 
2.7.4 (Apple Git-66)

[PATCH v3 0/4] Support DAX for device-mapper linear devices

[Mike Snitzer]

Jens, please pick up the first 2 block patches and I'll get the other
2 DM patches staged for 4.8.

v3:
 - fixed "warning: context imbalance in 'dm_blk_direct_access' -
   different lock contexts for basic block" due to missing
   dm_put_live_table in dm_blk_direct_access's dm_get_live_table error
   path
 - refactored dm-table.c code to centralize checking if all devices in
   a DM table support DAX (removed need for target to set
   ->dax_supported)
 - included Yigal Korman's patch to add 'dax' sysfs attribute

Toshi Kani (3):
  block: add QUEUE_FLAG_DAX for devices to advertise their DAX support
  dm: add infrastructure for DAX support
  dm linear: add DAX support

Yigal Korman (1):
  block: expose QUEUE_FLAG_DAX in sysfs

 block/blk-sysfs.c             | 11 +++++++++++
 drivers/block/brd.c           |  4 +++-
 drivers/md/dm-linear.c        | 21 ++++++++++++++++++++-
 drivers/md/dm-table.c         | 44 ++++++++++++++++++++++++++++++++++++++++++-
 drivers/md/dm.c               | 38 +++++++++++++++++++++++++++++++++++--
 drivers/md/dm.h               |  1 +
 drivers/nvdimm/pmem.c         |  1 +
 drivers/s390/block/dcssblk.c  |  1 +
 fs/block_dev.c                |  5 +++--
 include/linux/blkdev.h        |  2 ++
 include/linux/device-mapper.h | 10 ++++++++++
 include/uapi/linux/dm-ioctl.h |  4 ++--
 12 files changed, 133 insertions(+), 9 deletions(-)

-- 
2.7.4 (Apple Git-66)

[PATCH v3 1/4] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support

[Mike Snitzer]

From: Toshi Kani <toshi.kani-ZPxbGqLxI0U@public.gmane.org>

Currently, presence of direct_access() in block_device_operations
indicates support of DAX on its block device.  Because
block_device_operations is instantiated with 'const', this DAX
capablity may not be enabled conditinally.

In preparation for supporting DAX to device-mapper devices, add
QUEUE_FLAG_DAX to request_queue flags to advertise their DAX
support.  This will allow to set the DAX capability based on how
mapped device is composed.

Signed-off-by: Toshi Kani <toshi.kani-ZPxbGqLxI0U@public.gmane.org>
Acked-by: Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
Cc: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Martin Schwidefsky <schwidefsky-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
Cc: Heiko Carstens <heiko.carstens-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
Cc: <linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
---
 drivers/block/brd.c          | 4 +++-
 drivers/nvdimm/pmem.c        | 1 +
 drivers/s390/block/dcssblk.c | 1 +
 fs/block_dev.c               | 5 +++--
 include/linux/blkdev.h       | 2 ++
 5 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index f5b0d6f..dd96a93 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -509,7 +509,9 @@ static struct brd_device *brd_alloc(int i)
 	blk_queue_max_discard_sectors(brd->brd_queue, UINT_MAX);
 	brd->brd_queue->limits.discard_zeroes_data = 1;
 	queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, brd->brd_queue);
-
+#ifdef CONFIG_BLK_DEV_RAM_DAX
+	queue_flag_set_unlocked(QUEUE_FLAG_DAX, brd->brd_queue);
+#endif
 	disk = brd->brd_disk = alloc_disk(max_part);
 	if (!disk)
 		goto out_free_queue;
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 608fc44..53b701b 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -283,6 +283,7 @@ static int pmem_attach_disk(struct device *dev,
 	blk_queue_max_hw_sectors(q, UINT_MAX);
 	blk_queue_bounce_limit(q, BLK_BOUNCE_ANY);
 	queue_flag_set_unlocked(QUEUE_FLAG_NONROT, q);
+	queue_flag_set_unlocked(QUEUE_FLAG_DAX, q);
 	q->queuedata = pmem;
 
 	disk = alloc_disk_node(0, nid);
diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c
index bed53c4..093e9e1 100644
--- a/drivers/s390/block/dcssblk.c
+++ b/drivers/s390/block/dcssblk.c
@@ -618,6 +618,7 @@ dcssblk_add_store(struct device *dev, struct device_attribute *attr, const char
 	dev_info->gd->driverfs_dev = &dev_info->dev;
 	blk_queue_make_request(dev_info->dcssblk_queue, dcssblk_make_request);
 	blk_queue_logical_block_size(dev_info->dcssblk_queue, 4096);
+	queue_flag_set_unlocked(QUEUE_FLAG_DAX, dev_info->dcssblk_queue);
 
 	seg_byte_size = (dev_info->end - dev_info->start + 1);
 	set_capacity(dev_info->gd, seg_byte_size >> 9); // size in sectors
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 71ccab1..d012be4 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -493,7 +493,7 @@ long bdev_direct_access(struct block_device *bdev, struct blk_dax_ctl *dax)
 
 	if (size < 0)
 		return size;
-	if (!ops->direct_access)
+	if (!blk_queue_dax(bdev_get_queue(bdev)) || !ops->direct_access)
 		return -EOPNOTSUPP;
 	if ((sector + DIV_ROUND_UP(size, 512)) >
 					part_nr_sects_read(bdev->bd_part))
@@ -1287,7 +1287,8 @@ static int __blkdev_get(struct block_device *bdev, fmode_t mode, int for_part)
 		bdev->bd_disk = disk;
 		bdev->bd_queue = disk->queue;
 		bdev->bd_contains = bdev;
-		if (IS_ENABLED(CONFIG_BLK_DEV_DAX) && disk->fops->direct_access)
+		if (IS_ENABLED(CONFIG_BLK_DEV_DAX) &&
+		    blk_queue_dax(disk->queue))
 			bdev->bd_inode->i_flags = S_DAX;
 		else
 			bdev->bd_inode->i_flags = 0;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 9746d22..1493ab3 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -505,6 +505,7 @@ struct request_queue {
 #define QUEUE_FLAG_WC	       23	/* Write back caching */
 #define QUEUE_FLAG_FUA	       24	/* device supports FUA writes */
 #define QUEUE_FLAG_FLUSH_NQ    25	/* flush not queueuable */
+#define QUEUE_FLAG_DAX         26	/* device supports DAX */
 
 #define QUEUE_FLAG_DEFAULT	((1 << QUEUE_FLAG_IO_STAT) |		\
 				 (1 << QUEUE_FLAG_STACKABLE)	|	\
@@ -594,6 +595,7 @@ static inline void queue_flag_clear(unsigned int flag, struct request_queue *q)
 #define blk_queue_discard(q)	test_bit(QUEUE_FLAG_DISCARD, &(q)->queue_flags)
 #define blk_queue_secdiscard(q)	(blk_queue_discard(q) && \
 	test_bit(QUEUE_FLAG_SECDISCARD, &(q)->queue_flags))
+#define blk_queue_dax(q)	test_bit(QUEUE_FLAG_DAX, &(q)->queue_flags)
 
 #define blk_noretry_request(rq) \
 	((rq)->cmd_flags & (REQ_FAILFAST_DEV|REQ_FAILFAST_TRANSPORT| \
-- 
2.7.4 (Apple Git-66)

[PATCH v3 1/4] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support

[Mike Snitzer]

From: Toshi Kani <toshi.kani@hpe.com>

Currently, presence of direct_access() in block_device_operations
indicates support of DAX on its block device.  Because
block_device_operations is instantiated with 'const', this DAX
capablity may not be enabled conditinally.

In preparation for supporting DAX to device-mapper devices, add
QUEUE_FLAG_DAX to request_queue flags to advertise their DAX
support.  This will allow to set the DAX capability based on how
mapped device is composed.

Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: <linux-s390@vger.kernel.org>
---
 drivers/block/brd.c          | 4 +++-
 drivers/nvdimm/pmem.c        | 1 +
 drivers/s390/block/dcssblk.c | 1 +
 fs/block_dev.c               | 5 +++--
 include/linux/blkdev.h       | 2 ++
 5 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index f5b0d6f..dd96a93 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -509,7 +509,9 @@ static struct brd_device *brd_alloc(int i)
 	blk_queue_max_discard_sectors(brd->brd_queue, UINT_MAX);
 	brd->brd_queue->limits.discard_zeroes_data = 1;
 	queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, brd->brd_queue);
-
+#ifdef CONFIG_BLK_DEV_RAM_DAX
+	queue_flag_set_unlocked(QUEUE_FLAG_DAX, brd->brd_queue);
+#endif
 	disk = brd->brd_disk = alloc_disk(max_part);
 	if (!disk)
 		goto out_free_queue;
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 608fc44..53b701b 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -283,6 +283,7 @@ static int pmem_attach_disk(struct device *dev,
 	blk_queue_max_hw_sectors(q, UINT_MAX);
 	blk_queue_bounce_limit(q, BLK_BOUNCE_ANY);
 	queue_flag_set_unlocked(QUEUE_FLAG_NONROT, q);
+	queue_flag_set_unlocked(QUEUE_FLAG_DAX, q);
 	q->queuedata = pmem;
 
 	disk = alloc_disk_node(0, nid);
diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c
index bed53c4..093e9e1 100644
--- a/drivers/s390/block/dcssblk.c
+++ b/drivers/s390/block/dcssblk.c
@@ -618,6 +618,7 @@ dcssblk_add_store(struct device *dev, struct device_attribute *attr, const char
 	dev_info->gd->driverfs_dev = &dev_info->dev;
 	blk_queue_make_request(dev_info->dcssblk_queue, dcssblk_make_request);
 	blk_queue_logical_block_size(dev_info->dcssblk_queue, 4096);
+	queue_flag_set_unlocked(QUEUE_FLAG_DAX, dev_info->dcssblk_queue);
 
 	seg_byte_size = (dev_info->end - dev_info->start + 1);
 	set_capacity(dev_info->gd, seg_byte_size >> 9); // size in sectors
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 71ccab1..d012be4 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -493,7 +493,7 @@ long bdev_direct_access(struct block_device *bdev, struct blk_dax_ctl *dax)
 
 	if (size < 0)
 		return size;
-	if (!ops->direct_access)
+	if (!blk_queue_dax(bdev_get_queue(bdev)) || !ops->direct_access)
 		return -EOPNOTSUPP;
 	if ((sector + DIV_ROUND_UP(size, 512)) >
 					part_nr_sects_read(bdev->bd_part))
@@ -1287,7 +1287,8 @@ static int __blkdev_get(struct block_device *bdev, fmode_t mode, int for_part)
 		bdev->bd_disk = disk;
 		bdev->bd_queue = disk->queue;
 		bdev->bd_contains = bdev;
-		if (IS_ENABLED(CONFIG_BLK_DEV_DAX) && disk->fops->direct_access)
+		if (IS_ENABLED(CONFIG_BLK_DEV_DAX) &&
+		    blk_queue_dax(disk->queue))
 			bdev->bd_inode->i_flags = S_DAX;
 		else
 			bdev->bd_inode->i_flags = 0;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 9746d22..1493ab3 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -505,6 +505,7 @@ struct request_queue {
 #define QUEUE_FLAG_WC	       23	/* Write back caching */
 #define QUEUE_FLAG_FUA	       24	/* device supports FUA writes */
 #define QUEUE_FLAG_FLUSH_NQ    25	/* flush not queueuable */
+#define QUEUE_FLAG_DAX         26	/* device supports DAX */
 
 #define QUEUE_FLAG_DEFAULT	((1 << QUEUE_FLAG_IO_STAT) |		\
 				 (1 << QUEUE_FLAG_STACKABLE)	|	\
@@ -594,6 +595,7 @@ static inline void queue_flag_clear(unsigned int flag, struct request_queue *q)
 #define blk_queue_discard(q)	test_bit(QUEUE_FLAG_DISCARD, &(q)->queue_flags)
 #define blk_queue_secdiscard(q)	(blk_queue_discard(q) && \
 	test_bit(QUEUE_FLAG_SECDISCARD, &(q)->queue_flags))
+#define blk_queue_dax(q)	test_bit(QUEUE_FLAG_DAX, &(q)->queue_flags)
 
 #define blk_noretry_request(rq) \
 	((rq)->cmd_flags & (REQ_FAILFAST_DEV|REQ_FAILFAST_TRANSPORT| \
-- 
2.7.4 (Apple Git-66)

[PATCH v3 2/4] block: expose QUEUE_FLAG_DAX in sysfs

[Mike Snitzer]

From: Yigal Korman <yigal-/8YdC2HfS5554TAoqtyWWQ@public.gmane.org>

Provides the ability to identify DAX enabled devices in userspace.

Signed-off-by: Yigal Korman <yigal-/8YdC2HfS5554TAoqtyWWQ@public.gmane.org>
Signed-off-by: Toshi Kani <toshi.kani-ZPxbGqLxI0U@public.gmane.org>
Acked-by: Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 block/blk-sysfs.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index 9920596..f87a7e7 100644
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
@@ -379,6 +379,11 @@ static ssize_t queue_wc_store(struct request_queue *q, const char *page,
 	return count;
 }
 
+static ssize_t queue_dax_show(struct request_queue *q, char *page)
+{
+	return queue_var_show(blk_queue_dax(q), page);
+}
+
 static struct queue_sysfs_entry queue_requests_entry = {
 	.attr = {.name = "nr_requests", .mode = S_IRUGO | S_IWUSR },
 	.show = queue_requests_show,
@@ -516,6 +521,11 @@ static struct queue_sysfs_entry queue_wc_entry = {
 	.store = queue_wc_store,
 };
 
+static struct queue_sysfs_entry queue_dax_entry = {
+	.attr = {.name = "dax", .mode = S_IRUGO },
+	.show = queue_dax_show,
+};
+
 static struct attribute *default_attrs[] = {
 	&queue_requests_entry.attr,
 	&queue_ra_entry.attr,
@@ -542,6 +552,7 @@ static struct attribute *default_attrs[] = {
 	&queue_random_entry.attr,
 	&queue_poll_entry.attr,
 	&queue_wc_entry.attr,
+	&queue_dax_entry.attr,
 	NULL,
 };
 
-- 
2.7.4 (Apple Git-66)

[PATCH v3 2/4] block: expose QUEUE_FLAG_DAX in sysfs

[Mike Snitzer]

From: Yigal Korman <yigal@plexistor.com>

Provides the ability to identify DAX enabled devices in userspace.

Signed-off-by: Yigal Korman <yigal@plexistor.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
---
 block/blk-sysfs.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index 9920596..f87a7e7 100644
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
@@ -379,6 +379,11 @@ static ssize_t queue_wc_store(struct request_queue *q, const char *page,
 	return count;
 }
 
+static ssize_t queue_dax_show(struct request_queue *q, char *page)
+{
+	return queue_var_show(blk_queue_dax(q), page);
+}
+
 static struct queue_sysfs_entry queue_requests_entry = {
 	.attr = {.name = "nr_requests", .mode = S_IRUGO | S_IWUSR },
 	.show = queue_requests_show,
@@ -516,6 +521,11 @@ static struct queue_sysfs_entry queue_wc_entry = {
 	.store = queue_wc_store,
 };
 
+static struct queue_sysfs_entry queue_dax_entry = {
+	.attr = {.name = "dax", .mode = S_IRUGO },
+	.show = queue_dax_show,
+};
+
 static struct attribute *default_attrs[] = {
 	&queue_requests_entry.attr,
 	&queue_ra_entry.attr,
@@ -542,6 +552,7 @@ static struct attribute *default_attrs[] = {
 	&queue_random_entry.attr,
 	&queue_poll_entry.attr,
 	&queue_wc_entry.attr,
+	&queue_dax_entry.attr,
 	NULL,
 };
 
-- 
2.7.4 (Apple Git-66)

[PATCH v3 3/4] dm: add infrastructure for DAX support

[Mike Snitzer]

From: Toshi Kani <toshi.kani-ZPxbGqLxI0U@public.gmane.org>

Change mapped device to implement direct_access function,
dm_blk_direct_access(), which calls a target direct_access function.
'struct target_type' is extended to have target direct_access interface.
This function limits direct accessible size to the dm_target's limit
with max_io_len().

Add dm_table_supports_dax() to iterate all targets and associated block
devices to check for DAX support.  To add DAX support to a DM target the
target must only implement the direct_access function.

Add a new dm type, DM_TYPE_DAX_BIO_BASED, which indicates that mapped
device supports DAX and is bio based.  This new type is used to assure
that all target devices have DAX support and remain that way after
QUEUE_FLAG_DAX is set in mapped device.

At initial table load, QUEUE_FLAG_DAX is set to mapped device when setting
DM_TYPE_DAX_BIO_BASED to the type.  Any subsequent table load to the
mapped device must have the same type, or else it fails per the check in
table_load().

Signed-off-by: Toshi Kani <toshi.kani-ZPxbGqLxI0U@public.gmane.org>
Signed-off-by: Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Alasdair Kergon <agk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
 drivers/md/dm-table.c         | 44 ++++++++++++++++++++++++++++++++++++++++++-
 drivers/md/dm.c               | 38 +++++++++++++++++++++++++++++++++++--
 drivers/md/dm.h               |  1 +
 include/linux/device-mapper.h | 10 ++++++++++
 include/uapi/linux/dm-ioctl.h |  4 ++--
 5 files changed, 92 insertions(+), 5 deletions(-)

diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index 88f0174..ee6f37e 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -827,6 +827,12 @@ void dm_consume_args(struct dm_arg_set *as, unsigned num_args)
 }
 EXPORT_SYMBOL(dm_consume_args);
 
+static bool __table_type_bio_based(unsigned table_type)
+{
+	return (table_type == DM_TYPE_BIO_BASED ||
+		table_type == DM_TYPE_DAX_BIO_BASED);
+}
+
 static bool __table_type_request_based(unsigned table_type)
 {
 	return (table_type == DM_TYPE_REQUEST_BASED ||
@@ -839,6 +845,34 @@ void dm_table_set_type(struct dm_table *t, unsigned type)
 }
 EXPORT_SYMBOL_GPL(dm_table_set_type);
 
+static int device_supports_dax(struct dm_target *ti, struct dm_dev *dev,
+			       sector_t start, sector_t len, void *data)
+{
+	struct request_queue *q = bdev_get_queue(dev->bdev);
+
+	return q && blk_queue_dax(q);
+}
+
+static bool dm_table_supports_dax(struct dm_table *t)
+{
+	struct dm_target *ti;
+	unsigned i = 0;
+
+	/* Ensure that all targets support DAX. */
+	while (i < dm_table_get_num_targets(t)) {
+		ti = dm_table_get_target(t, i++);
+
+		if (!ti->type->direct_access)
+			return false;
+
+		if (!ti->type->iterate_devices ||
+		    !ti->type->iterate_devices(ti, device_supports_dax, NULL))
+			return false;
+	}
+
+	return true;
+}
+
 static int dm_table_determine_type(struct dm_table *t)
 {
 	unsigned i;
@@ -853,6 +887,7 @@ static int dm_table_determine_type(struct dm_table *t)
 		/* target already set the table's type */
 		if (t->type == DM_TYPE_BIO_BASED)
 			return 0;
+		BUG_ON(t->type == DM_TYPE_DAX_BIO_BASED);
 		goto verify_rq_based;
 	}
 
@@ -887,6 +922,8 @@ static int dm_table_determine_type(struct dm_table *t)
 	if (bio_based) {
 		/* We must use this table as bio-based */
 		t->type = DM_TYPE_BIO_BASED;
+		if (dm_table_supports_dax(t))
+			t->type = DM_TYPE_DAX_BIO_BASED;
 		return 0;
 	}
 
@@ -979,6 +1016,11 @@ struct dm_target *dm_table_get_wildcard_target(struct dm_table *t)
 	return NULL;
 }
 
+bool dm_table_bio_based(struct dm_table *t)
+{
+	return __table_type_bio_based(dm_table_get_type(t));
+}
+
 bool dm_table_request_based(struct dm_table *t)
 {
 	return __table_type_request_based(dm_table_get_type(t));
@@ -1001,7 +1043,7 @@ static int dm_table_alloc_md_mempools(struct dm_table *t, struct mapped_device *
 		return -EINVAL;
 	}
 
-	if (type == DM_TYPE_BIO_BASED)
+	if (__table_type_bio_based(type))
 		for (i = 0; i < t->num_targets; i++) {
 			tgt = t->targets + i;
 			per_io_data_size = max(per_io_data_size, tgt->per_io_data_size);
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 2c907bc..62f6c24 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -905,6 +905,33 @@ int dm_set_target_max_io_len(struct dm_target *ti, sector_t len)
 }
 EXPORT_SYMBOL_GPL(dm_set_target_max_io_len);
 
+static long dm_blk_direct_access(struct block_device *bdev, sector_t sector,
+				 void __pmem **kaddr, pfn_t *pfn, long size)
+{
+	struct mapped_device *md = bdev->bd_disk->private_data;
+	struct dm_table *map;
+	struct dm_target *ti;
+	int srcu_idx;
+	long len, ret = -EIO;
+
+	map = dm_get_live_table(md, &srcu_idx);
+	if (!map)
+		goto out;
+
+	ti = dm_table_find_target(map, sector);
+	if (!dm_target_is_valid(ti))
+		goto out;
+
+	len = max_io_len(sector, ti) << SECTOR_SHIFT;
+	size = min(len, size);
+
+	if (ti->type->direct_access)
+		ret = ti->type->direct_access(ti, sector, kaddr, pfn, size);
+out:
+	dm_put_live_table(md, srcu_idx);
+	return min(ret, size);
+}
+
 /*
  * A target may call dm_accept_partial_bio only from the map routine.  It is
  * allowed for all bio types except REQ_PREFLUSH.
@@ -1548,7 +1575,7 @@ static void __bind_mempools(struct mapped_device *md, struct dm_table *t)
 
 	if (md->bs) {
 		/* The md already has necessary mempools. */
-		if (dm_table_get_type(t) == DM_TYPE_BIO_BASED) {
+		if (dm_table_bio_based(t)) {
 			/*
 			 * Reload bioset because front_pad may have changed
 			 * because a different table was loaded.
@@ -1744,8 +1771,9 @@ EXPORT_SYMBOL_GPL(dm_get_queue_limits);
 int dm_setup_md_queue(struct mapped_device *md, struct dm_table *t)
 {
 	int r;
+	unsigned type = dm_get_md_type(md);
 
-	switch (dm_get_md_type(md)) {
+	switch (type) {
 	case DM_TYPE_REQUEST_BASED:
 		r = dm_old_init_request_queue(md);
 		if (r) {
@@ -1761,6 +1789,7 @@ int dm_setup_md_queue(struct mapped_device *md, struct dm_table *t)
 		}
 		break;
 	case DM_TYPE_BIO_BASED:
+	case DM_TYPE_DAX_BIO_BASED:
 		dm_init_normal_md_queue(md);
 		blk_queue_make_request(md->queue, dm_make_request);
 		/*
@@ -1769,6 +1798,9 @@ int dm_setup_md_queue(struct mapped_device *md, struct dm_table *t)
 		 */
 		bioset_free(md->queue->bio_split);
 		md->queue->bio_split = NULL;
+
+		if (type == DM_TYPE_DAX_BIO_BASED)
+			queue_flag_set_unlocked(QUEUE_FLAG_DAX, md->queue);
 		break;
 	}
 
@@ -2465,6 +2497,7 @@ struct dm_md_mempools *dm_alloc_md_mempools(struct mapped_device *md, unsigned t
 
 	switch (type) {
 	case DM_TYPE_BIO_BASED:
+	case DM_TYPE_DAX_BIO_BASED:
 		cachep = _io_cache;
 		pool_size = dm_get_reserved_bio_based_ios();
 		front_pad = roundup(per_io_data_size, __alignof__(struct dm_target_io)) + offsetof(struct dm_target_io, clone);
@@ -2641,6 +2674,7 @@ static const struct block_device_operations dm_blk_dops = {
 	.open = dm_blk_open,
 	.release = dm_blk_close,
 	.ioctl = dm_blk_ioctl,
+	.direct_access = dm_blk_direct_access,
 	.getgeo = dm_blk_getgeo,
 	.pr_ops = &dm_pr_ops,
 	.owner = THIS_MODULE
diff --git a/drivers/md/dm.h b/drivers/md/dm.h
index 2e0e4a5..f0aad08 100644
--- a/drivers/md/dm.h
+++ b/drivers/md/dm.h
@@ -68,6 +68,7 @@ unsigned dm_table_get_type(struct dm_table *t);
 struct target_type *dm_table_get_immutable_target_type(struct dm_table *t);
 struct dm_target *dm_table_get_immutable_target(struct dm_table *t);
 struct dm_target *dm_table_get_wildcard_target(struct dm_table *t);
+bool dm_table_bio_based(struct dm_table *t);
 bool dm_table_request_based(struct dm_table *t);
 bool dm_table_all_blk_mq_devices(struct dm_table *t);
 void dm_table_free_md_mempools(struct dm_table *t);
diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
index 2ce3392..b0db857 100644
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -26,6 +26,7 @@ struct bio_vec;
 #define DM_TYPE_BIO_BASED		1
 #define DM_TYPE_REQUEST_BASED		2
 #define DM_TYPE_MQ_REQUEST_BASED	3
+#define DM_TYPE_DAX_BIO_BASED		4
 
 typedef enum { STATUSTYPE_INFO, STATUSTYPE_TABLE } status_type_t;
 
@@ -124,6 +125,14 @@ typedef void (*dm_io_hints_fn) (struct dm_target *ti,
  */
 typedef int (*dm_busy_fn) (struct dm_target *ti);
 
+/*
+ * Returns:
+ *  < 0 : error
+ * >= 0 : the number of bytes accessible at the address
+ */
+typedef long (*dm_direct_access_fn) (struct dm_target *ti, sector_t sector,
+				     void __pmem **kaddr, pfn_t *pfn, long size);
+
 void dm_error(const char *message);
 
 struct dm_dev {
@@ -170,6 +179,7 @@ struct target_type {
 	dm_busy_fn busy;
 	dm_iterate_devices_fn iterate_devices;
 	dm_io_hints_fn io_hints;
+	dm_direct_access_fn direct_access;
 
 	/* For internal device-mapper use. */
 	struct list_head list;
diff --git a/include/uapi/linux/dm-ioctl.h b/include/uapi/linux/dm-ioctl.h
index 30afd0a..4bf9f1e 100644
--- a/include/uapi/linux/dm-ioctl.h
+++ b/include/uapi/linux/dm-ioctl.h
@@ -267,9 +267,9 @@ enum {
 #define DM_DEV_SET_GEOMETRY	_IOWR(DM_IOCTL, DM_DEV_SET_GEOMETRY_CMD, struct dm_ioctl)
 
 #define DM_VERSION_MAJOR	4
-#define DM_VERSION_MINOR	34
+#define DM_VERSION_MINOR	35
 #define DM_VERSION_PATCHLEVEL	0
-#define DM_VERSION_EXTRA	"-ioctl (2015-10-28)"
+#define DM_VERSION_EXTRA	"-ioctl (2016-06-23)"
 
 /* Status bits */
 #define DM_READONLY_FLAG	(1 << 0) /* In/Out */
-- 
2.7.4 (Apple Git-66)

[PATCH v3 3/4] dm: add infrastructure for DAX support

[Mike Snitzer]

From: Toshi Kani <toshi.kani@hpe.com>

Change mapped device to implement direct_access function,
dm_blk_direct_access(), which calls a target direct_access function.
'struct target_type' is extended to have target direct_access interface.
This function limits direct accessible size to the dm_target's limit
with max_io_len().

Add dm_table_supports_dax() to iterate all targets and associated block
devices to check for DAX support.  To add DAX support to a DM target the
target must only implement the direct_access function.

Add a new dm type, DM_TYPE_DAX_BIO_BASED, which indicates that mapped
device supports DAX and is bio based.  This new type is used to assure
that all target devices have DAX support and remain that way after
QUEUE_FLAG_DAX is set in mapped device.

At initial table load, QUEUE_FLAG_DAX is set to mapped device when setting
DM_TYPE_DAX_BIO_BASED to the type.  Any subsequent table load to the
mapped device must have the same type, or else it fails per the check in
table_load().

Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: Alasdair Kergon <agk@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
---
 drivers/md/dm-table.c         | 44 ++++++++++++++++++++++++++++++++++++++++++-
 drivers/md/dm.c               | 38 +++++++++++++++++++++++++++++++++++--
 drivers/md/dm.h               |  1 +
 include/linux/device-mapper.h | 10 ++++++++++
 include/uapi/linux/dm-ioctl.h |  4 ++--
 5 files changed, 92 insertions(+), 5 deletions(-)

diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index 88f0174..ee6f37e 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -827,6 +827,12 @@ void dm_consume_args(struct dm_arg_set *as, unsigned num_args)
 }
 EXPORT_SYMBOL(dm_consume_args);
 
+static bool __table_type_bio_based(unsigned table_type)
+{
+	return (table_type == DM_TYPE_BIO_BASED ||
+		table_type == DM_TYPE_DAX_BIO_BASED);
+}
+
 static bool __table_type_request_based(unsigned table_type)
 {
 	return (table_type == DM_TYPE_REQUEST_BASED ||
@@ -839,6 +845,34 @@ void dm_table_set_type(struct dm_table *t, unsigned type)
 }
 EXPORT_SYMBOL_GPL(dm_table_set_type);
 
+static int device_supports_dax(struct dm_target *ti, struct dm_dev *dev,
+			       sector_t start, sector_t len, void *data)
+{
+	struct request_queue *q = bdev_get_queue(dev->bdev);
+
+	return q && blk_queue_dax(q);
+}
+
+static bool dm_table_supports_dax(struct dm_table *t)
+{
+	struct dm_target *ti;
+	unsigned i = 0;
+
+	/* Ensure that all targets support DAX. */
+	while (i < dm_table_get_num_targets(t)) {
+		ti = dm_table_get_target(t, i++);
+
+		if (!ti->type->direct_access)
+			return false;
+
+		if (!ti->type->iterate_devices ||
+		    !ti->type->iterate_devices(ti, device_supports_dax, NULL))
+			return false;
+	}
+
+	return true;
+}
+
 static int dm_table_determine_type(struct dm_table *t)
 {
 	unsigned i;
@@ -853,6 +887,7 @@ static int dm_table_determine_type(struct dm_table *t)
 		/* target already set the table's type */
 		if (t->type == DM_TYPE_BIO_BASED)
 			return 0;
+		BUG_ON(t->type == DM_TYPE_DAX_BIO_BASED);
 		goto verify_rq_based;
 	}
 
@@ -887,6 +922,8 @@ static int dm_table_determine_type(struct dm_table *t)
 	if (bio_based) {
 		/* We must use this table as bio-based */
 		t->type = DM_TYPE_BIO_BASED;
+		if (dm_table_supports_dax(t))
+			t->type = DM_TYPE_DAX_BIO_BASED;
 		return 0;
 	}
 
@@ -979,6 +1016,11 @@ struct dm_target *dm_table_get_wildcard_target(struct dm_table *t)
 	return NULL;
 }
 
+bool dm_table_bio_based(struct dm_table *t)
+{
+	return __table_type_bio_based(dm_table_get_type(t));
+}
+
 bool dm_table_request_based(struct dm_table *t)
 {
 	return __table_type_request_based(dm_table_get_type(t));
@@ -1001,7 +1043,7 @@ static int dm_table_alloc_md_mempools(struct dm_table *t, struct mapped_device *
 		return -EINVAL;
 	}
 
-	if (type == DM_TYPE_BIO_BASED)
+	if (__table_type_bio_based(type))
 		for (i = 0; i < t->num_targets; i++) {
 			tgt = t->targets + i;
 			per_io_data_size = max(per_io_data_size, tgt->per_io_data_size);
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 2c907bc..62f6c24 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -905,6 +905,33 @@ int dm_set_target_max_io_len(struct dm_target *ti, sector_t len)
 }
 EXPORT_SYMBOL_GPL(dm_set_target_max_io_len);
 
+static long dm_blk_direct_access(struct block_device *bdev, sector_t sector,
+				 void __pmem **kaddr, pfn_t *pfn, long size)
+{
+	struct mapped_device *md = bdev->bd_disk->private_data;
+	struct dm_table *map;
+	struct dm_target *ti;
+	int srcu_idx;
+	long len, ret = -EIO;
+
+	map = dm_get_live_table(md, &srcu_idx);
+	if (!map)
+		goto out;
+
+	ti = dm_table_find_target(map, sector);
+	if (!dm_target_is_valid(ti))
+		goto out;
+
+	len = max_io_len(sector, ti) << SECTOR_SHIFT;
+	size = min(len, size);
+
+	if (ti->type->direct_access)
+		ret = ti->type->direct_access(ti, sector, kaddr, pfn, size);
+out:
+	dm_put_live_table(md, srcu_idx);
+	return min(ret, size);
+}
+
 /*
  * A target may call dm_accept_partial_bio only from the map routine.  It is
  * allowed for all bio types except REQ_PREFLUSH.
@@ -1548,7 +1575,7 @@ static void __bind_mempools(struct mapped_device *md, struct dm_table *t)
 
 	if (md->bs) {
 		/* The md already has necessary mempools. */
-		if (dm_table_get_type(t) == DM_TYPE_BIO_BASED) {
+		if (dm_table_bio_based(t)) {
 			/*
 			 * Reload bioset because front_pad may have changed
 			 * because a different table was loaded.
@@ -1744,8 +1771,9 @@ EXPORT_SYMBOL_GPL(dm_get_queue_limits);
 int dm_setup_md_queue(struct mapped_device *md, struct dm_table *t)
 {
 	int r;
+	unsigned type = dm_get_md_type(md);
 
-	switch (dm_get_md_type(md)) {
+	switch (type) {
 	case DM_TYPE_REQUEST_BASED:
 		r = dm_old_init_request_queue(md);
 		if (r) {
@@ -1761,6 +1789,7 @@ int dm_setup_md_queue(struct mapped_device *md, struct dm_table *t)
 		}
 		break;
 	case DM_TYPE_BIO_BASED:
+	case DM_TYPE_DAX_BIO_BASED:
 		dm_init_normal_md_queue(md);
 		blk_queue_make_request(md->queue, dm_make_request);
 		/*
@@ -1769,6 +1798,9 @@ int dm_setup_md_queue(struct mapped_device *md, struct dm_table *t)
 		 */
 		bioset_free(md->queue->bio_split);
 		md->queue->bio_split = NULL;
+
+		if (type == DM_TYPE_DAX_BIO_BASED)
+			queue_flag_set_unlocked(QUEUE_FLAG_DAX, md->queue);
 		break;
 	}
 
@@ -2465,6 +2497,7 @@ struct dm_md_mempools *dm_alloc_md_mempools(struct mapped_device *md, unsigned t
 
 	switch (type) {
 	case DM_TYPE_BIO_BASED:
+	case DM_TYPE_DAX_BIO_BASED:
 		cachep = _io_cache;
 		pool_size = dm_get_reserved_bio_based_ios();
 		front_pad = roundup(per_io_data_size, __alignof__(struct dm_target_io)) + offsetof(struct dm_target_io, clone);
@@ -2641,6 +2674,7 @@ static const struct block_device_operations dm_blk_dops = {
 	.open = dm_blk_open,
 	.release = dm_blk_close,
 	.ioctl = dm_blk_ioctl,
+	.direct_access = dm_blk_direct_access,
 	.getgeo = dm_blk_getgeo,
 	.pr_ops = &dm_pr_ops,
 	.owner = THIS_MODULE
diff --git a/drivers/md/dm.h b/drivers/md/dm.h
index 2e0e4a5..f0aad08 100644
--- a/drivers/md/dm.h
+++ b/drivers/md/dm.h
@@ -68,6 +68,7 @@ unsigned dm_table_get_type(struct dm_table *t);
 struct target_type *dm_table_get_immutable_target_type(struct dm_table *t);
 struct dm_target *dm_table_get_immutable_target(struct dm_table *t);
 struct dm_target *dm_table_get_wildcard_target(struct dm_table *t);
+bool dm_table_bio_based(struct dm_table *t);
 bool dm_table_request_based(struct dm_table *t);
 bool dm_table_all_blk_mq_devices(struct dm_table *t);
 void dm_table_free_md_mempools(struct dm_table *t);
diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
index 2ce3392..b0db857 100644
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -26,6 +26,7 @@ struct bio_vec;
 #define DM_TYPE_BIO_BASED		1
 #define DM_TYPE_REQUEST_BASED		2
 #define DM_TYPE_MQ_REQUEST_BASED	3
+#define DM_TYPE_DAX_BIO_BASED		4
 
 typedef enum { STATUSTYPE_INFO, STATUSTYPE_TABLE } status_type_t;
 
@@ -124,6 +125,14 @@ typedef void (*dm_io_hints_fn) (struct dm_target *ti,
  */
 typedef int (*dm_busy_fn) (struct dm_target *ti);
 
+/*
+ * Returns:
+ *  < 0 : error
+ * >= 0 : the number of bytes accessible at the address
+ */
+typedef long (*dm_direct_access_fn) (struct dm_target *ti, sector_t sector,
+				     void __pmem **kaddr, pfn_t *pfn, long size);
+
 void dm_error(const char *message);
 
 struct dm_dev {
@@ -170,6 +179,7 @@ struct target_type {
 	dm_busy_fn busy;
 	dm_iterate_devices_fn iterate_devices;
 	dm_io_hints_fn io_hints;
+	dm_direct_access_fn direct_access;
 
 	/* For internal device-mapper use. */
 	struct list_head list;
diff --git a/include/uapi/linux/dm-ioctl.h b/include/uapi/linux/dm-ioctl.h
index 30afd0a..4bf9f1e 100644
--- a/include/uapi/linux/dm-ioctl.h
+++ b/include/uapi/linux/dm-ioctl.h
@@ -267,9 +267,9 @@ enum {
 #define DM_DEV_SET_GEOMETRY	_IOWR(DM_IOCTL, DM_DEV_SET_GEOMETRY_CMD, struct dm_ioctl)
 
 #define DM_VERSION_MAJOR	4
-#define DM_VERSION_MINOR	34
+#define DM_VERSION_MINOR	35
 #define DM_VERSION_PATCHLEVEL	0
-#define DM_VERSION_EXTRA	"-ioctl (2015-10-28)"
+#define DM_VERSION_EXTRA	"-ioctl (2016-06-23)"
 
 /* Status bits */
 #define DM_READONLY_FLAG	(1 << 0) /* In/Out */
-- 
2.7.4 (Apple Git-66)

Re: [PATCH v3 3/4] dm: add infrastructure for DAX support

[Kani, Toshimitsu]

On Thu, 2016-06-23 at 17:05 -0400, Mike Snitzer wrote:
 :
> +static int device_supports_dax(struct dm_target *ti, struct dm_dev *dev,
> +			       sector_t start, sector_t len, void *data)
> +{
> +	struct request_queue *q = bdev_get_queue(dev->bdev);
> +
> +	return q && blk_queue_dax(q);
> +}
> +
> +static bool dm_table_supports_dax(struct dm_table *t)
> +{
> +	struct dm_target *ti;
> +	unsigned i = 0;
> +
> +	/* Ensure that all targets support DAX. */
> +	while (i < dm_table_get_num_targets(t)) {
> +		ti = dm_table_get_target(t, i++);
> +
> +		if (!ti->type->direct_access)
> +			return false;
> +
> +		if (!ti->type->iterate_devices ||
> +		    !ti->type->iterate_devices(ti, device_supports_dax,
> NULL))
> +			return false;
> +	}
> +
> +	return true;
> +}
> +

Hi Mike,

Thanks for the update.  I have a question about the above change.  Targets may
have their own parameters.  For instance, dm-stripe has 'chunk_size', which is
checked in stripe_ctr().  DAX adds additional restriction that chunk_size
needs to be aligned by page size.  So, I think we need to keep target
responsible to verify if DAX can be supported.  What do you think?

Thanks,
-Toshi
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH v3 3/4] dm: add infrastructure for DAX support

[Kani, Toshimitsu]

On Thu, 2016-06-23 at 17:05 -0400, Mike Snitzer wrote:
 :
> +static int device_supports_dax(struct dm_target *ti, struct dm_dev *dev,
> +			       sector_t start, sector_t len, void *data)
> +{
> +	struct request_queue *q = bdev_get_queue(dev->bdev);
> +
> +	return q && blk_queue_dax(q);
> +}
> +
> +static bool dm_table_supports_dax(struct dm_table *t)
> +{
> +	struct dm_target *ti;
> +	unsigned i = 0;
> +
> +	/* Ensure that all targets support DAX. */
> +	while (i < dm_table_get_num_targets(t)) {
> +		ti = dm_table_get_target(t, i++);
> +
> +		if (!ti->type->direct_access)
> +			return false;
> +
> +		if (!ti->type->iterate_devices ||
> +		    !ti->type->iterate_devices(ti, device_supports_dax,
> NULL))
> +			return false;
> +	}
> +
> +	return true;
> +}
> +

Hi Mike,

Thanks for the update.  I have a question about the above change.  Targets may
have their own parameters.  For instance, dm-stripe has 'chunk_size', which is
checked in stripe_ctr().  DAX adds additional restriction that chunk_size
needs to be aligned by page size.  So, I think we need to keep target
responsible to verify if DAX can be supported.  What do you think?

Thanks,
-Toshi

Re: [PATCH v3 3/4] dm: add infrastructure for DAX support

[Mike Snitzer]

On Thu, Jun 23 2016 at  7:36pm -0400,
Kani, Toshimitsu <toshi.kani-ZPxbGqLxI0U@public.gmane.org> wrote:

> On Thu, 2016-06-23 at 17:05 -0400, Mike Snitzer wrote:
>  :
> > +static int device_supports_dax(struct dm_target *ti, struct dm_dev *dev,
> > +			       sector_t start, sector_t len, void *data)
> > +{
> > +	struct request_queue *q = bdev_get_queue(dev->bdev);
> > +
> > +	return q && blk_queue_dax(q);
> > +}
> > +
> > +static bool dm_table_supports_dax(struct dm_table *t)
> > +{
> > +	struct dm_target *ti;
> > +	unsigned i = 0;
> > +
> > +	/* Ensure that all targets support DAX. */
> > +	while (i < dm_table_get_num_targets(t)) {
> > +		ti = dm_table_get_target(t, i++);
> > +
> > +		if (!ti->type->direct_access)
> > +			return false;
> > +
> > +		if (!ti->type->iterate_devices ||
> > +		    !ti->type->iterate_devices(ti, device_supports_dax,
> > NULL))
> > +			return false;
> > +	}
> > +
> > +	return true;
> > +}
> > +
> 
> Hi Mike,
> 
> Thanks for the update.  I have a question about the above change.  Targets may
> have their own parameters.  For instance, dm-stripe has 'chunk_size', which is
> checked in stripe_ctr().  DAX adds additional restriction that chunk_size
> needs to be aligned by page size.  So, I think we need to keep target
> responsible to verify if DAX can be supported.  What do you think?

We've never had to concern the dm-stripe target with hardware
specific chunk_size validation.  The user is able to specify the
chunk_size via lvm2's lvcreate -I argument.  Yes this gives users enough
rope to hang themselves but it is very easy to configure a dm-stripe
device with the appropriate chunk size (PAGE_SIZE) from userspace.

But lvm2 could even be trained to make sure the chunk_size is a factor
of physical_block_size (PAGE_SIZE in the case of pmem) if the underlying
devices export queue/dax=1

Re: [PATCH v3 3/4] dm: add infrastructure for DAX support

[Mike Snitzer]

On Thu, Jun 23 2016 at  7:36pm -0400,
Kani, Toshimitsu <toshi.kani@hpe.com> wrote:

> On Thu, 2016-06-23 at 17:05 -0400, Mike Snitzer wrote:
>  :
> > +static int device_supports_dax(struct dm_target *ti, struct dm_dev *dev,
> > +			       sector_t start, sector_t len, void *data)
> > +{
> > +	struct request_queue *q = bdev_get_queue(dev->bdev);
> > +
> > +	return q && blk_queue_dax(q);
> > +}
> > +
> > +static bool dm_table_supports_dax(struct dm_table *t)
> > +{
> > +	struct dm_target *ti;
> > +	unsigned i = 0;
> > +
> > +	/* Ensure that all targets support DAX. */
> > +	while (i < dm_table_get_num_targets(t)) {
> > +		ti = dm_table_get_target(t, i++);
> > +
> > +		if (!ti->type->direct_access)
> > +			return false;
> > +
> > +		if (!ti->type->iterate_devices ||
> > +		    !ti->type->iterate_devices(ti, device_supports_dax,
> > NULL))
> > +			return false;
> > +	}
> > +
> > +	return true;
> > +}
> > +
> 
> Hi Mike,
> 
> Thanks for the update.  I have a question about the above change.  Targets may
> have their own parameters.  For instance, dm-stripe has 'chunk_size', which is
> checked in stripe_ctr().  DAX adds additional restriction that chunk_size
> needs to be aligned by page size.  So, I think we need to keep target
> responsible to verify if DAX can be supported.  What do you think?

We've never had to concern the dm-stripe target with hardware
specific chunk_size validation.  The user is able to specify the
chunk_size via lvm2's lvcreate -I argument.  Yes this gives users enough
rope to hang themselves but it is very easy to configure a dm-stripe
device with the appropriate chunk size (PAGE_SIZE) from userspace.

But lvm2 could even be trained to make sure the chunk_size is a factor
of physical_block_size (PAGE_SIZE in the case of pmem) if the underlying
devices export queue/dax=1

Re: [PATCH v3 3/4] dm: add infrastructure for DAX support

[Kani, Toshimitsu]

On Thu, 2016-06-23 at 21:49 -0400, Mike Snitzer wrote:
> On Thu, Jun 23 2016 at  7:36pm -0400,
> Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
 :
> > Thanks for the update.  I have a question about the above change.  Targets
> > may have their own parameters.  For instance, dm-stripe has 'chunk_size',
> > which is checked in stripe_ctr().  DAX adds additional restriction that
> > chunk_size needs to be aligned by page size.  So, I think we need to keep
> > target responsible to verify if DAX can be supported.  What do you think?
>
> We've never had to concern the dm-stripe target with hardware
> specific chunk_size validation.  The user is able to specify the
> chunk_size via lvm2's lvcreate -I argument.  Yes this gives users enough
> rope to hang themselves but it is very easy to configure a dm-stripe
> device with the appropriate chunk size (PAGE_SIZE) from userspace.
> 
> But lvm2 could even be trained to make sure the chunk_size is a factor
> of physical_block_size (PAGE_SIZE in the case of pmem) if the underlying
> devices export queue/dax=1

lvcreate -I only allows multiple of page size, so we are OK with lvm2.  I was
wondering if the check in lvm2 is enough.  Are there any other tools that may
be used to configure stripe size?  Can we trust userspace on this?

Thanks,
-Toshi
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH v3 3/4] dm: add infrastructure for DAX support

[Kani, Toshimitsu]

On Thu, 2016-06-23 at 21:49 -0400, Mike Snitzer wrote:
> On Thu, Jun 23 2016 at  7:36pm -0400,
> Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
 :
> > Thanks for the update.  I have a question about the above change.  Targets
> > may have their own parameters.  For instance, dm-stripe has 'chunk_size',
> > which is checked in stripe_ctr().  DAX adds additional restriction that
> > chunk_size needs to be aligned by page size.  So, I think we need to keep
> > target responsible to verify if DAX can be supported.  What do you think?
>
> We've never had to concern the dm-stripe target with hardware
> specific chunk_size validation.  The user is able to specify the
> chunk_size via lvm2's lvcreate -I argument.  Yes this gives users enough
> rope to hang themselves but it is very easy to configure a dm-stripe
> device with the appropriate chunk size (PAGE_SIZE) from userspace.
> 
> But lvm2 could even be trained to make sure the chunk_size is a factor
> of physical_block_size (PAGE_SIZE in the case of pmem) if the underlying
> devices export queue/dax=1

lvcreate -I only allows multiple of page size, so we are OK with lvm2.  I was
wondering if the check in lvm2 is enough.  Are there any other tools that may
be used to configure stripe size?  Can we trust userspace on this?

Thanks,
-Toshi

Re: [PATCH v3 3/4] dm: add infrastructure for DAX support

[Mike Snitzer]

On Fri, Jun 24 2016 at 11:40am -0400,
Kani, Toshimitsu <toshi.kani-ZPxbGqLxI0U@public.gmane.org> wrote:

> On Thu, 2016-06-23 at 21:49 -0400, Mike Snitzer wrote:
> > On Thu, Jun 23 2016 at  7:36pm -0400,
> > Kani, Toshimitsu <toshi.kani-ZPxbGqLxI0U@public.gmane.org> wrote:
>  :
> > > Thanks for the update.  I have a question about the above change.  Targets
> > > may have their own parameters.  For instance, dm-stripe has 'chunk_size',
> > > which is checked in stripe_ctr().  DAX adds additional restriction that
> > > chunk_size needs to be aligned by page size.  So, I think we need to keep
> > > target responsible to verify if DAX can be supported.  What do you think?
> >
> > We've never had to concern the dm-stripe target with hardware
> > specific chunk_size validation.  The user is able to specify the
> > chunk_size via lvm2's lvcreate -I argument.  Yes this gives users enough
> > rope to hang themselves but it is very easy to configure a dm-stripe
> > device with the appropriate chunk size (PAGE_SIZE) from userspace.
> > 
> > But lvm2 could even be trained to make sure the chunk_size is a factor
> > of physical_block_size (PAGE_SIZE in the case of pmem) if the underlying
> > devices export queue/dax=1
> 
> lvcreate -I only allows multiple of page size, so we are OK with lvm2.  I was
> wondering if the check in lvm2 is enough.  Are there any other tools that may
> be used to configure stripe size?  Can we trust userspace on this?

Other than lvm2, I'm not aware of any other userspace tool that is
driving the dm-stripe target configuration.  So I think we can trust
userspace here until proven otherwise.  Good news is that any
misconfiguration will simply not work right?  Errors would result from
improperly sized IO right?

Re: [PATCH v3 3/4] dm: add infrastructure for DAX support

[Mike Snitzer]

On Fri, Jun 24 2016 at 11:40am -0400,
Kani, Toshimitsu <toshi.kani@hpe.com> wrote:

> On Thu, 2016-06-23 at 21:49 -0400, Mike Snitzer wrote:
> > On Thu, Jun 23 2016 at  7:36pm -0400,
> > Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
>  :
> > > Thanks for the update.  I have a question about the above change.  Targets
> > > may have their own parameters.  For instance, dm-stripe has 'chunk_size',
> > > which is checked in stripe_ctr().  DAX adds additional restriction that
> > > chunk_size needs to be aligned by page size.  So, I think we need to keep
> > > target responsible to verify if DAX can be supported.  What do you think?
> >
> > We've never had to concern the dm-stripe target with hardware
> > specific chunk_size validation.  The user is able to specify the
> > chunk_size via lvm2's lvcreate -I argument.  Yes this gives users enough
> > rope to hang themselves but it is very easy to configure a dm-stripe
> > device with the appropriate chunk size (PAGE_SIZE) from userspace.
> > 
> > But lvm2 could even be trained to make sure the chunk_size is a factor
> > of physical_block_size (PAGE_SIZE in the case of pmem) if the underlying
> > devices export queue/dax=1
> 
> lvcreate -I only allows multiple of page size, so we are OK with lvm2.  I was
> wondering if the check in lvm2 is enough.  Are there any other tools that may
> be used to configure stripe size?  Can we trust userspace on this?

Other than lvm2, I'm not aware of any other userspace tool that is
driving the dm-stripe target configuration.  So I think we can trust
userspace here until proven otherwise.  Good news is that any
misconfiguration will simply not work right?  Errors would result from
improperly sized IO right?

Re: [PATCH v3 3/4] dm: add infrastructure for DAX support

[Kani, Toshimitsu]

On Fri, 2016-06-24 at 11:44 -0400, Mike Snitzer wrote:
> On Fri, Jun 24 2016 at 11:40am -0400,
> Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
> > On Thu, 2016-06-23 at 21:49 -0400, Mike Snitzer wrote:
> > > 
> > > On Thu, Jun 23 2016 at  7:36pm -0400,
> > > Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
> > > > Thanks for the update.  I have a question about the above change.
> > > >  Targets may have their own parameters.  For instance, dm-stripe has
> > > > 'chunk_size', which is checked in stripe_ctr().  DAX adds additional
> > > > restriction that chunk_size needs to be aligned by page size.  So, I
> > > > think we need to keep target responsible to verify if DAX can be
> > > > supported.  What do you think?
> > > 
> > > We've never had to concern the dm-stripe target with hardware
> > > specific chunk_size validation.  The user is able to specify the
> > > chunk_size via lvm2's lvcreate -I argument.  Yes this gives users enough
> > > rope to hang themselves but it is very easy to configure a dm-stripe
> > > device with the appropriate chunk size (PAGE_SIZE) from userspace.
> > > 
> > > But lvm2 could even be trained to make sure the chunk_size is a factor
> > > of physical_block_size (PAGE_SIZE in the case of pmem) if the underlying
> > > devices export queue/dax=1
> >
> > lvcreate -I only allows multiple of page size, so we are OK with lvm2.  I
> > was wondering if the check in lvm2 is enough.  Are there any other tools
> > that may be used to configure stripe size?  Can we trust userspace on
> > this?
>
> Other than lvm2, I'm not aware of any other userspace tool that is
> driving the dm-stripe target configuration.  So I think we can trust
> userspace here until proven otherwise.  

Good.

> Good news is that any
> misconfiguration will simply not work right?  Errors would result from
> improperly sized IO right?

dax provides direct access with respect to data.  So, yes, IO to data fails,
but IO to metadata still succeeds.  This may result in creating empty files,
etc.

Thanks,
-Toshi
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH v3 3/4] dm: add infrastructure for DAX support

[Kani, Toshimitsu]

On Fri, 2016-06-24 at 11:44 -0400, Mike Snitzer wrote:
> On Fri, Jun 24 2016 at 11:40am -0400,
> Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
> > On Thu, 2016-06-23 at 21:49 -0400, Mike Snitzer wrote:
> > > 
> > > On Thu, Jun 23 2016 at  7:36pm -0400,
> > > Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
> > > > Thanks for the update.  I have a question about the above change.
> > > >  Targets may have their own parameters.  For instance, dm-stripe has
> > > > 'chunk_size', which is checked in stripe_ctr().  DAX adds additional
> > > > restriction that chunk_size needs to be aligned by page size.  So, I
> > > > think we need to keep target responsible to verify if DAX can be
> > > > supported.  What do you think?
> > > 
> > > We've never had to concern the dm-stripe target with hardware
> > > specific chunk_size validation.  The user is able to specify the
> > > chunk_size via lvm2's lvcreate -I argument.  Yes this gives users enough
> > > rope to hang themselves but it is very easy to configure a dm-stripe
> > > device with the appropriate chunk size (PAGE_SIZE) from userspace.
> > > 
> > > But lvm2 could even be trained to make sure the chunk_size is a factor
> > > of physical_block_size (PAGE_SIZE in the case of pmem) if the underlying
> > > devices export queue/dax=1
> >
> > lvcreate -I only allows multiple of page size, so we are OK with lvm2.  I
> > was wondering if the check in lvm2 is enough.  Are there any other tools
> > that may be used to configure stripe size?  Can we trust userspace on
> > this?
>
> Other than lvm2, I'm not aware of any other userspace tool that is
> driving the dm-stripe target configuration.  So I think we can trust
> userspace here until proven otherwise.  

Good.

> Good news is that any
> misconfiguration will simply not work right?  Errors would result from
> improperly sized IO right?

dax provides direct access with respect to data.  So, yes, IO to data fails,
but IO to metadata still succeeds.  This may result in creating empty files,
etc.

Thanks,
-Toshi

[PATCH v3 4/4] dm linear: add DAX support

[Mike Snitzer]

From: Toshi Kani <toshi.kani-ZPxbGqLxI0U@public.gmane.org>

Change dm-linear to implement direct_access function,
linear_direct_access(), which maps sector and calls direct_access
function of its physical target device.

Signed-off-by: Toshi Kani <toshi.kani-ZPxbGqLxI0U@public.gmane.org>
Signed-off-by: Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Alasdair Kergon <agk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
 drivers/md/dm-linear.c | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/md/dm-linear.c b/drivers/md/dm-linear.c
index 05c35aa..6d35dd4 100644
--- a/drivers/md/dm-linear.c
+++ b/drivers/md/dm-linear.c
@@ -141,9 +141,27 @@ static int linear_iterate_devices(struct dm_target *ti,
 	return fn(ti, lc->dev, lc->start, ti->len, data);
 }
 
+static long linear_direct_access(struct dm_target *ti, sector_t sector,
+				 void __pmem **kaddr, pfn_t *pfn, long size)
+{
+	struct linear_c *lc = ti->private;
+	struct block_device *bdev = lc->dev->bdev;
+	struct blk_dax_ctl dax = {
+		.sector = linear_map_sector(ti, sector),
+		.size = size,
+	};
+	long ret;
+
+	ret = bdev_direct_access(bdev, &dax);
+	*kaddr = dax.addr;
+	*pfn = dax.pfn;
+
+	return ret;
+}
+
 static struct target_type linear_target = {
 	.name   = "linear",
-	.version = {1, 2, 1},
+	.version = {1, 3, 0},
 	.module = THIS_MODULE,
 	.ctr    = linear_ctr,
 	.dtr    = linear_dtr,
@@ -151,6 +169,7 @@ static struct target_type linear_target = {
 	.status = linear_status,
 	.prepare_ioctl = linear_prepare_ioctl,
 	.iterate_devices = linear_iterate_devices,
+	.direct_access = linear_direct_access,
 };
 
 int __init dm_linear_init(void)
-- 
2.7.4 (Apple Git-66)

[PATCH v3 4/4] dm linear: add DAX support

[Mike Snitzer]

From: Toshi Kani <toshi.kani@hpe.com>

Change dm-linear to implement direct_access function,
linear_direct_access(), which maps sector and calls direct_access
function of its physical target device.

Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: Alasdair Kergon <agk@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
---
 drivers/md/dm-linear.c | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/md/dm-linear.c b/drivers/md/dm-linear.c
index 05c35aa..6d35dd4 100644
--- a/drivers/md/dm-linear.c
+++ b/drivers/md/dm-linear.c
@@ -141,9 +141,27 @@ static int linear_iterate_devices(struct dm_target *ti,
 	return fn(ti, lc->dev, lc->start, ti->len, data);
 }
 
+static long linear_direct_access(struct dm_target *ti, sector_t sector,
+				 void __pmem **kaddr, pfn_t *pfn, long size)
+{
+	struct linear_c *lc = ti->private;
+	struct block_device *bdev = lc->dev->bdev;
+	struct blk_dax_ctl dax = {
+		.sector = linear_map_sector(ti, sector),
+		.size = size,
+	};
+	long ret;
+
+	ret = bdev_direct_access(bdev, &dax);
+	*kaddr = dax.addr;
+	*pfn = dax.pfn;
+
+	return ret;
+}
+
 static struct target_type linear_target = {
 	.name   = "linear",
-	.version = {1, 2, 1},
+	.version = {1, 3, 0},
 	.module = THIS_MODULE,
 	.ctr    = linear_ctr,
 	.dtr    = linear_dtr,
@@ -151,6 +169,7 @@ static struct target_type linear_target = {
 	.status = linear_status,
 	.prepare_ioctl = linear_prepare_ioctl,
 	.iterate_devices = linear_iterate_devices,
+	.direct_access = linear_direct_access,
 };
 
 int __init dm_linear_init(void)
-- 
2.7.4 (Apple Git-66)

Re: [PATCH v3 0/4] Support DAX for device-mapper linear devices

[Mike Snitzer]

On Thu, Jun 23 2016 at  5:05pm -0400,
Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

> Jens, please pick up the first 2 block patches and I'll get the other
> 2 DM patches staged for 4.8.

Hey Jens,

Looks like you're back so I figured I'd ping you on these first 2 block
patches again.  Can you pick them up for 4.8/core?

Thanks,
Mike

Re: [PATCH v3 0/4] Support DAX for device-mapper linear devices

[Mike Snitzer]

On Thu, Jun 23 2016 at  5:05pm -0400,
Mike Snitzer <snitzer@redhat.com> wrote:

> Jens, please pick up the first 2 block patches and I'll get the other
> 2 DM patches staged for 4.8.

Hey Jens,

Looks like you're back so I figured I'd ping you on these first 2 block
patches again.  Can you pick them up for 4.8/core?

Thanks,
Mike

Re: [PATCH v3 0/4] Support DAX for device-mapper linear devices

[Mike Snitzer]

On Thu, Jun 30 2016 at  1:00pm -0400,
Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

> On Thu, Jun 23 2016 at  5:05pm -0400,
> Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> 
> > Jens, please pick up the first 2 block patches and I'll get the other
> > 2 DM patches staged for 4.8.
> 
> Hey Jens,
> 
> Looks like you're back so I figured I'd ping you on these first 2 block
> patches again.  Can you pick them up for 4.8/core?
> 
> Thanks,
> Mike

ping^2

Re: [PATCH v3 0/4] Support DAX for device-mapper linear devices

[Mike Snitzer]

On Thu, Jun 30 2016 at  1:00pm -0400,
Mike Snitzer <snitzer@redhat.com> wrote:

> On Thu, Jun 23 2016 at  5:05pm -0400,
> Mike Snitzer <snitzer@redhat.com> wrote:
> 
> > Jens, please pick up the first 2 block patches and I'll get the other
> > 2 DM patches staged for 4.8.
> 
> Hey Jens,
> 
> Looks like you're back so I figured I'd ping you on these first 2 block
> patches again.  Can you pick them up for 4.8/core?
> 
> Thanks,
> Mike

ping^2