* [PATCH v3 0/2] dax, dm: stop requiring dax for device-mapper @ 2017-08-02 17:57 ` Dan Williams 0 siblings, 0 replies; 17+ messages in thread From: Dan Williams @ 2017-08-02 17:57 UTC (permalink / raw) To: snitzer Cc: kbuild test robot, linux-nvdimm, Michael Ellerman, Heiko Carstens, linux-kernel, Bart Van Assche, dm-devel, Paul Mackerras, Gerald Schaefer, Benjamin Herrenschmidt, Martin Schwidefsky, Alasdair Kergon Changes since v2 [1]: * rebase on -next to integrate with commit 273752c9ff03 "dm, dax: Make sure dm_dax_flush() is called if device supports it" (kbuild robot) * fix CONFIG_DAX dependencies to upgrade CONFIG_DAX=m to CONFIG_DAX=y (kbuild robot) [1]: https://www.spinics.net/lists/kernel/msg2570522.html --- Bart points out that the DAX core is unconditionally enabled if device-mapper is enabled. Add some config machinery and some stub-static-inline routines to allow dax infrastructure to be deleted from device-mapper at compile time. Since this depends on commit 273752c9ff03 that's already in -next, this should go through the device-mapper tree. --- Dan Williams (2): dax: introduce CONFIG_DAX_DRIVER dm: allow device-mapper to operate without dax support arch/powerpc/platforms/Kconfig | 1 + drivers/block/Kconfig | 1 + drivers/dax/Kconfig | 4 +++- drivers/md/Kconfig | 2 +- drivers/md/dm-linear.c | 6 ++++++ drivers/md/dm-stripe.c | 6 ++++++ drivers/md/dm.c | 10 ++++++---- drivers/nvdimm/Kconfig | 1 + drivers/s390/block/Kconfig | 1 + include/linux/dax.h | 30 ++++++++++++++++++++++++------ 10 files changed, 50 insertions(+), 12 deletions(-) _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH v3 0/2] dax, dm: stop requiring dax for device-mapper @ 2017-08-02 17:57 ` Dan Williams 0 siblings, 0 replies; 17+ messages in thread From: Dan Williams @ 2017-08-02 17:57 UTC (permalink / raw) To: snitzer Cc: kbuild test robot, linux-nvdimm, Michael Ellerman, Heiko Carstens, linux-kernel, Martin Schwidefsky, dm-devel, Paul Mackerras, Alasdair Kergon, Benjamin Herrenschmidt, Bart Van Assche, Gerald Schaefer Changes since v2 [1]: * rebase on -next to integrate with commit 273752c9ff03 "dm, dax: Make sure dm_dax_flush() is called if device supports it" (kbuild robot) * fix CONFIG_DAX dependencies to upgrade CONFIG_DAX=m to CONFIG_DAX=y (kbuild robot) [1]: https://www.spinics.net/lists/kernel/msg2570522.html --- Bart points out that the DAX core is unconditionally enabled if device-mapper is enabled. Add some config machinery and some stub-static-inline routines to allow dax infrastructure to be deleted from device-mapper at compile time. Since this depends on commit 273752c9ff03 that's already in -next, this should go through the device-mapper tree. --- Dan Williams (2): dax: introduce CONFIG_DAX_DRIVER dm: allow device-mapper to operate without dax support arch/powerpc/platforms/Kconfig | 1 + drivers/block/Kconfig | 1 + drivers/dax/Kconfig | 4 +++- drivers/md/Kconfig | 2 +- drivers/md/dm-linear.c | 6 ++++++ drivers/md/dm-stripe.c | 6 ++++++ drivers/md/dm.c | 10 ++++++---- drivers/nvdimm/Kconfig | 1 + drivers/s390/block/Kconfig | 1 + include/linux/dax.h | 30 ++++++++++++++++++++++++------ 10 files changed, 50 insertions(+), 12 deletions(-) ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH v3 1/2] dax: introduce CONFIG_DAX_DRIVER 2017-08-02 17:57 ` Dan Williams (?) @ 2017-08-02 17:58 ` Dan Williams -1 siblings, 0 replies; 17+ messages in thread From: Dan Williams @ 2017-08-02 17:58 UTC (permalink / raw) To: snitzer Cc: linux-nvdimm, Michael Ellerman, Heiko Carstens, linux-kernel, Bart Van Assche, dm-devel, Paul Mackerras, Benjamin Herrenschmidt, Martin Schwidefsky, Gerald Schaefer In support of allowing device-mapper to compile out idle/dead code when there are no dax providers in the system, introduce the DAX_DRIVER symbol. This is selected by all leaf drivers that device-mapper might be layered on top. This allows device-mapper to 'select DAX', i.e. upgrade it from DAX=m to DAX=y, when a provider is present. Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Mike Snitzer <snitzer@redhat.com> Cc: Bart Van Assche <Bart.VanAssche@wdc.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> --- arch/powerpc/platforms/Kconfig | 1 + drivers/block/Kconfig | 1 + drivers/dax/Kconfig | 4 +++- drivers/nvdimm/Kconfig | 1 + drivers/s390/block/Kconfig | 1 + 5 files changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig index 4fd64d3f5c44..4561340c1f92 100644 --- a/arch/powerpc/platforms/Kconfig +++ b/arch/powerpc/platforms/Kconfig @@ -296,6 +296,7 @@ config AXON_RAM tristate "Axon DDR2 memory device driver" depends on PPC_IBM_CELL_BLADE && BLOCK select DAX + select DAX_DRIVER default m help It registers one block device per Axon's DDR2 memory bank found diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index 8ddc98279c8f..e1b6f4d2a716 100644 --- a/drivers/block/Kconfig +++ b/drivers/block/Kconfig @@ -324,6 +324,7 @@ config BLK_DEV_SX8 config BLK_DEV_RAM tristate "RAM block device support" select DAX if BLK_DEV_RAM_DAX + select DAX_DRIVER if BLK_DEV_RAM_DAX ---help--- Saying Y here will allow you to use a portion of your RAM memory as a block device, so that you can make file systems on it, read and diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig index b79aa8f7a497..9bf940eb9c06 100644 --- a/drivers/dax/Kconfig +++ b/drivers/dax/Kconfig @@ -1,3 +1,6 @@ +config DAX_DRIVER + bool + menuconfig DAX tristate "DAX: direct access to differentiated memory" select SRCU @@ -16,7 +19,6 @@ config DEV_DAX baseline memory pool. Mappings of a /dev/daxX.Y device impose restrictions that make the mapping behavior deterministic. - config DEV_DAX_PMEM tristate "PMEM DAX: direct access to persistent memory" depends on LIBNVDIMM && NVDIMM_DAX && DEV_DAX diff --git a/drivers/nvdimm/Kconfig b/drivers/nvdimm/Kconfig index 5bdd499b5f4f..afe4018d76cf 100644 --- a/drivers/nvdimm/Kconfig +++ b/drivers/nvdimm/Kconfig @@ -21,6 +21,7 @@ config BLK_DEV_PMEM tristate "PMEM: Persistent memory block device support" default LIBNVDIMM select DAX + select DAX_DRIVER select ND_BTT if BTT select ND_PFN if NVDIMM_PFN help diff --git a/drivers/s390/block/Kconfig b/drivers/s390/block/Kconfig index 31f014b57bfc..3f563f2f33d6 100644 --- a/drivers/s390/block/Kconfig +++ b/drivers/s390/block/Kconfig @@ -15,6 +15,7 @@ config BLK_DEV_XPRAM config DCSSBLK def_tristate m select DAX + select DAX_DRIVER prompt "DCSSBLK support" depends on S390 && BLOCK help _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v3 1/2] dax: introduce CONFIG_DAX_DRIVER @ 2017-08-02 17:58 ` Dan Williams 0 siblings, 0 replies; 17+ messages in thread From: Dan Williams @ 2017-08-02 17:58 UTC (permalink / raw) To: snitzer-H+wXaHxf7aLQT0dZR+AlfA Cc: linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Michael Ellerman, Heiko Carstens, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Bart Van Assche, dm-devel-H+wXaHxf7aLQT0dZR+AlfA, Paul Mackerras, Benjamin Herrenschmidt, Martin Schwidefsky, Gerald Schaefer In support of allowing device-mapper to compile out idle/dead code when there are no dax providers in the system, introduce the DAX_DRIVER symbol. This is selected by all leaf drivers that device-mapper might be layered on top. This allows device-mapper to 'select DAX', i.e. upgrade it from DAX=m to DAX=y, when a provider is present. Cc: Paul Mackerras <paulus-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> Cc: Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org> Cc: Martin Schwidefsky <schwidefsky-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org> Cc: Heiko Carstens <heiko.carstens-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org> Cc: Gerald Schaefer <gerald.schaefer-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org> Cc: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> Cc: Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Cc: Bart Van Assche <Bart.VanAssche-Sjgp3cTcYWE@public.gmane.org> Signed-off-by: Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> --- arch/powerpc/platforms/Kconfig | 1 + drivers/block/Kconfig | 1 + drivers/dax/Kconfig | 4 +++- drivers/nvdimm/Kconfig | 1 + drivers/s390/block/Kconfig | 1 + 5 files changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig index 4fd64d3f5c44..4561340c1f92 100644 --- a/arch/powerpc/platforms/Kconfig +++ b/arch/powerpc/platforms/Kconfig @@ -296,6 +296,7 @@ config AXON_RAM tristate "Axon DDR2 memory device driver" depends on PPC_IBM_CELL_BLADE && BLOCK select DAX + select DAX_DRIVER default m help It registers one block device per Axon's DDR2 memory bank found diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index 8ddc98279c8f..e1b6f4d2a716 100644 --- a/drivers/block/Kconfig +++ b/drivers/block/Kconfig @@ -324,6 +324,7 @@ config BLK_DEV_SX8 config BLK_DEV_RAM tristate "RAM block device support" select DAX if BLK_DEV_RAM_DAX + select DAX_DRIVER if BLK_DEV_RAM_DAX ---help--- Saying Y here will allow you to use a portion of your RAM memory as a block device, so that you can make file systems on it, read and diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig index b79aa8f7a497..9bf940eb9c06 100644 --- a/drivers/dax/Kconfig +++ b/drivers/dax/Kconfig @@ -1,3 +1,6 @@ +config DAX_DRIVER + bool + menuconfig DAX tristate "DAX: direct access to differentiated memory" select SRCU @@ -16,7 +19,6 @@ config DEV_DAX baseline memory pool. Mappings of a /dev/daxX.Y device impose restrictions that make the mapping behavior deterministic. - config DEV_DAX_PMEM tristate "PMEM DAX: direct access to persistent memory" depends on LIBNVDIMM && NVDIMM_DAX && DEV_DAX diff --git a/drivers/nvdimm/Kconfig b/drivers/nvdimm/Kconfig index 5bdd499b5f4f..afe4018d76cf 100644 --- a/drivers/nvdimm/Kconfig +++ b/drivers/nvdimm/Kconfig @@ -21,6 +21,7 @@ config BLK_DEV_PMEM tristate "PMEM: Persistent memory block device support" default LIBNVDIMM select DAX + select DAX_DRIVER select ND_BTT if BTT select ND_PFN if NVDIMM_PFN help diff --git a/drivers/s390/block/Kconfig b/drivers/s390/block/Kconfig index 31f014b57bfc..3f563f2f33d6 100644 --- a/drivers/s390/block/Kconfig +++ b/drivers/s390/block/Kconfig @@ -15,6 +15,7 @@ config BLK_DEV_XPRAM config DCSSBLK def_tristate m select DAX + select DAX_DRIVER prompt "DCSSBLK support" depends on S390 && BLOCK help ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v3 1/2] dax: introduce CONFIG_DAX_DRIVER @ 2017-08-02 17:58 ` Dan Williams 0 siblings, 0 replies; 17+ messages in thread From: Dan Williams @ 2017-08-02 17:58 UTC (permalink / raw) To: snitzer Cc: linux-nvdimm, Michael Ellerman, Heiko Carstens, linux-kernel, Martin Schwidefsky, dm-devel, Paul Mackerras, Benjamin Herrenschmidt, Bart Van Assche, Gerald Schaefer In support of allowing device-mapper to compile out idle/dead code when there are no dax providers in the system, introduce the DAX_DRIVER symbol. This is selected by all leaf drivers that device-mapper might be layered on top. This allows device-mapper to 'select DAX', i.e. upgrade it from DAX=m to DAX=y, when a provider is present. Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Mike Snitzer <snitzer@redhat.com> Cc: Bart Van Assche <Bart.VanAssche@wdc.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> --- arch/powerpc/platforms/Kconfig | 1 + drivers/block/Kconfig | 1 + drivers/dax/Kconfig | 4 +++- drivers/nvdimm/Kconfig | 1 + drivers/s390/block/Kconfig | 1 + 5 files changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig index 4fd64d3f5c44..4561340c1f92 100644 --- a/arch/powerpc/platforms/Kconfig +++ b/arch/powerpc/platforms/Kconfig @@ -296,6 +296,7 @@ config AXON_RAM tristate "Axon DDR2 memory device driver" depends on PPC_IBM_CELL_BLADE && BLOCK select DAX + select DAX_DRIVER default m help It registers one block device per Axon's DDR2 memory bank found diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index 8ddc98279c8f..e1b6f4d2a716 100644 --- a/drivers/block/Kconfig +++ b/drivers/block/Kconfig @@ -324,6 +324,7 @@ config BLK_DEV_SX8 config BLK_DEV_RAM tristate "RAM block device support" select DAX if BLK_DEV_RAM_DAX + select DAX_DRIVER if BLK_DEV_RAM_DAX ---help--- Saying Y here will allow you to use a portion of your RAM memory as a block device, so that you can make file systems on it, read and diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig index b79aa8f7a497..9bf940eb9c06 100644 --- a/drivers/dax/Kconfig +++ b/drivers/dax/Kconfig @@ -1,3 +1,6 @@ +config DAX_DRIVER + bool + menuconfig DAX tristate "DAX: direct access to differentiated memory" select SRCU @@ -16,7 +19,6 @@ config DEV_DAX baseline memory pool. Mappings of a /dev/daxX.Y device impose restrictions that make the mapping behavior deterministic. - config DEV_DAX_PMEM tristate "PMEM DAX: direct access to persistent memory" depends on LIBNVDIMM && NVDIMM_DAX && DEV_DAX diff --git a/drivers/nvdimm/Kconfig b/drivers/nvdimm/Kconfig index 5bdd499b5f4f..afe4018d76cf 100644 --- a/drivers/nvdimm/Kconfig +++ b/drivers/nvdimm/Kconfig @@ -21,6 +21,7 @@ config BLK_DEV_PMEM tristate "PMEM: Persistent memory block device support" default LIBNVDIMM select DAX + select DAX_DRIVER select ND_BTT if BTT select ND_PFN if NVDIMM_PFN help diff --git a/drivers/s390/block/Kconfig b/drivers/s390/block/Kconfig index 31f014b57bfc..3f563f2f33d6 100644 --- a/drivers/s390/block/Kconfig +++ b/drivers/s390/block/Kconfig @@ -15,6 +15,7 @@ config BLK_DEV_XPRAM config DCSSBLK def_tristate m select DAX + select DAX_DRIVER prompt "DCSSBLK support" depends on S390 && BLOCK help ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v3 2/2] dm: allow device-mapper to operate without dax support 2017-08-02 17:57 ` Dan Williams @ 2017-08-02 17:58 ` Dan Williams -1 siblings, 0 replies; 17+ messages in thread From: Dan Williams @ 2017-08-02 17:58 UTC (permalink / raw) To: snitzer Cc: kbuild test robot, linux-nvdimm, linux-kernel, dm-devel, Bart Van Assche, Alasdair Kergon Rather than have device-mapper directly 'select DAX', let the fact that BLK_DEV_PMEM selects dax act as a gate for the device-mapper dax support. We arrange for all the dax core routines to compile to nops when CONFIG_DAX=n. With that in place we can simply handle the alloc_dax() error as expected and ifdef out the other device-mapper-dax support code. Now, if dax is provided by a leaf driver that driver may only arrange to compile the dax core as a module. Since device-mapper dax support is consumed by the always-built-in portion of the device-mapper implementation we need to upgrade from DAX=m to DAX=y. Cc: Alasdair Kergon <agk@redhat.com> Cc: Mike Snitzer <snitzer@redhat.com> Reported-by: Bart Van Assche <Bart.VanAssche@wdc.com> Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> --- drivers/md/Kconfig | 2 +- drivers/md/dm-linear.c | 6 ++++++ drivers/md/dm-stripe.c | 6 ++++++ drivers/md/dm.c | 10 ++++++---- include/linux/dax.h | 30 ++++++++++++++++++++++++------ 5 files changed, 43 insertions(+), 11 deletions(-) diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig index 4a249ee86364..8ebf09e99006 100644 --- a/drivers/md/Kconfig +++ b/drivers/md/Kconfig @@ -195,12 +195,12 @@ config MD_CLUSTER source "drivers/md/bcache/Kconfig" config BLK_DEV_DM_BUILTIN + select DAX if DAX_DRIVER bool config BLK_DEV_DM tristate "Device mapper support" select BLK_DEV_DM_BUILTIN - select DAX ---help--- Device-mapper is a low level volume manager. It works by allowing people to specify mappings for ranges of logical sectors. Various diff --git a/drivers/md/dm-linear.c b/drivers/md/dm-linear.c index 41971a090e34..8804e278e834 100644 --- a/drivers/md/dm-linear.c +++ b/drivers/md/dm-linear.c @@ -154,6 +154,7 @@ static int linear_iterate_devices(struct dm_target *ti, return fn(ti, lc->dev, lc->start, ti->len, data); } +#if IS_ENABLED(CONFIG_DAX) static long linear_dax_direct_access(struct dm_target *ti, pgoff_t pgoff, long nr_pages, void **kaddr, pfn_t *pfn) { @@ -197,6 +198,11 @@ static void linear_dax_flush(struct dm_target *ti, pgoff_t pgoff, void *addr, return; dax_flush(dax_dev, pgoff, addr, size); } +#else +#define linear_dax_direct_access NULL +#define linear_dax_copy_from_iter NULL +#define linear_dax_flush NULL +#endif static struct target_type linear_target = { .name = "linear", diff --git a/drivers/md/dm-stripe.c b/drivers/md/dm-stripe.c index a0375530b07f..eeb6c784dc4f 100644 --- a/drivers/md/dm-stripe.c +++ b/drivers/md/dm-stripe.c @@ -311,6 +311,7 @@ static int stripe_map(struct dm_target *ti, struct bio *bio) return DM_MAPIO_REMAPPED; } +#if IS_ENABLED(CONFIG_DAX) static long stripe_dax_direct_access(struct dm_target *ti, pgoff_t pgoff, long nr_pages, void **kaddr, pfn_t *pfn) { @@ -369,6 +370,11 @@ static void stripe_dax_flush(struct dm_target *ti, pgoff_t pgoff, void *addr, return; dax_flush(dax_dev, pgoff, addr, size); } +#else +#define stripe_dax_direct_access NULL +#define stripe_dax_copy_from_iter NULL +#define stripe_dax_flush NULL +#endif /* * Stripe status: diff --git a/drivers/md/dm.c b/drivers/md/dm.c index 2edbcc2d7d3f..70fa48f4d3a3 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -1713,7 +1713,7 @@ static void cleanup_mapped_device(struct mapped_device *md) static struct mapped_device *alloc_dev(int minor) { int r, numa_node_id = dm_get_numa_node(); - struct dax_device *dax_dev; + struct dax_device *dax_dev = NULL; struct mapped_device *md; void *old_md; @@ -1779,9 +1779,11 @@ static struct mapped_device *alloc_dev(int minor) md->disk->private_data = md; sprintf(md->disk->disk_name, "dm-%d", minor); - dax_dev = alloc_dax(md, md->disk->disk_name, &dm_dax_ops); - if (!dax_dev) - goto bad; + if (IS_ENABLED(CONFIG_DAX)) { + dax_dev = alloc_dax(md, md->disk->disk_name, &dm_dax_ops); + if (!dax_dev) + goto bad; + } md->dax_dev = dax_dev; add_disk(md->disk); diff --git a/include/linux/dax.h b/include/linux/dax.h index eb0bff6f1eab..59575b8e638e 100644 --- a/include/linux/dax.h +++ b/include/linux/dax.h @@ -27,16 +27,39 @@ extern struct attribute_group dax_attribute_group; #if IS_ENABLED(CONFIG_DAX) struct dax_device *dax_get_by_host(const char *host); +struct dax_device *alloc_dax(void *private, const char *host, + const struct dax_operations *ops); void put_dax(struct dax_device *dax_dev); +void kill_dax(struct dax_device *dax_dev); +void dax_write_cache(struct dax_device *dax_dev, bool wc); +bool dax_write_cache_enabled(struct dax_device *dax_dev); #else static inline struct dax_device *dax_get_by_host(const char *host) { return NULL; } - +static inline struct dax_device *alloc_dax(void *private, const char *host, + const struct dax_operations *ops) +{ + /* + * Callers should check IS_ENABLED(CONFIG_DAX) to know if this + * NULL is an error or expected. + */ + return NULL; +} static inline void put_dax(struct dax_device *dax_dev) { } +static inline void kill_dax(struct dax_device *dax_dev) +{ +} +static inline void dax_write_cache(struct dax_device *dax_dev, bool wc) +{ +} +static inline bool dax_write_cache_enabled(struct dax_device *dax_dev) +{ + return false; +} #endif int bdev_dax_pgoff(struct block_device *, sector_t, size_t, pgoff_t *pgoff); @@ -75,10 +98,7 @@ static inline void fs_put_dax(struct dax_device *dax_dev) int dax_read_lock(void); void dax_read_unlock(int id); -struct dax_device *alloc_dax(void *private, const char *host, - const struct dax_operations *ops); bool dax_alive(struct dax_device *dax_dev); -void kill_dax(struct dax_device *dax_dev); void *dax_get_private(struct dax_device *dax_dev); long dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff, long nr_pages, void **kaddr, pfn_t *pfn); @@ -86,8 +106,6 @@ size_t dax_copy_from_iter(struct dax_device *dax_dev, pgoff_t pgoff, void *addr, size_t bytes, struct iov_iter *i); void dax_flush(struct dax_device *dax_dev, pgoff_t pgoff, void *addr, size_t size); -void dax_write_cache(struct dax_device *dax_dev, bool wc); -bool dax_write_cache_enabled(struct dax_device *dax_dev); ssize_t dax_iomap_rw(struct kiocb *iocb, struct iov_iter *iter, const struct iomap_ops *ops); _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v3 2/2] dm: allow device-mapper to operate without dax support @ 2017-08-02 17:58 ` Dan Williams 0 siblings, 0 replies; 17+ messages in thread From: Dan Williams @ 2017-08-02 17:58 UTC (permalink / raw) To: snitzer Cc: kbuild test robot, linux-nvdimm, linux-kernel, dm-devel, Bart Van Assche, Alasdair Kergon Rather than have device-mapper directly 'select DAX', let the fact that BLK_DEV_PMEM selects dax act as a gate for the device-mapper dax support. We arrange for all the dax core routines to compile to nops when CONFIG_DAX=n. With that in place we can simply handle the alloc_dax() error as expected and ifdef out the other device-mapper-dax support code. Now, if dax is provided by a leaf driver that driver may only arrange to compile the dax core as a module. Since device-mapper dax support is consumed by the always-built-in portion of the device-mapper implementation we need to upgrade from DAX=m to DAX=y. Cc: Alasdair Kergon <agk@redhat.com> Cc: Mike Snitzer <snitzer@redhat.com> Reported-by: Bart Van Assche <Bart.VanAssche@wdc.com> Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> --- drivers/md/Kconfig | 2 +- drivers/md/dm-linear.c | 6 ++++++ drivers/md/dm-stripe.c | 6 ++++++ drivers/md/dm.c | 10 ++++++---- include/linux/dax.h | 30 ++++++++++++++++++++++++------ 5 files changed, 43 insertions(+), 11 deletions(-) diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig index 4a249ee86364..8ebf09e99006 100644 --- a/drivers/md/Kconfig +++ b/drivers/md/Kconfig @@ -195,12 +195,12 @@ config MD_CLUSTER source "drivers/md/bcache/Kconfig" config BLK_DEV_DM_BUILTIN + select DAX if DAX_DRIVER bool config BLK_DEV_DM tristate "Device mapper support" select BLK_DEV_DM_BUILTIN - select DAX ---help--- Device-mapper is a low level volume manager. It works by allowing people to specify mappings for ranges of logical sectors. Various diff --git a/drivers/md/dm-linear.c b/drivers/md/dm-linear.c index 41971a090e34..8804e278e834 100644 --- a/drivers/md/dm-linear.c +++ b/drivers/md/dm-linear.c @@ -154,6 +154,7 @@ static int linear_iterate_devices(struct dm_target *ti, return fn(ti, lc->dev, lc->start, ti->len, data); } +#if IS_ENABLED(CONFIG_DAX) static long linear_dax_direct_access(struct dm_target *ti, pgoff_t pgoff, long nr_pages, void **kaddr, pfn_t *pfn) { @@ -197,6 +198,11 @@ static void linear_dax_flush(struct dm_target *ti, pgoff_t pgoff, void *addr, return; dax_flush(dax_dev, pgoff, addr, size); } +#else +#define linear_dax_direct_access NULL +#define linear_dax_copy_from_iter NULL +#define linear_dax_flush NULL +#endif static struct target_type linear_target = { .name = "linear", diff --git a/drivers/md/dm-stripe.c b/drivers/md/dm-stripe.c index a0375530b07f..eeb6c784dc4f 100644 --- a/drivers/md/dm-stripe.c +++ b/drivers/md/dm-stripe.c @@ -311,6 +311,7 @@ static int stripe_map(struct dm_target *ti, struct bio *bio) return DM_MAPIO_REMAPPED; } +#if IS_ENABLED(CONFIG_DAX) static long stripe_dax_direct_access(struct dm_target *ti, pgoff_t pgoff, long nr_pages, void **kaddr, pfn_t *pfn) { @@ -369,6 +370,11 @@ static void stripe_dax_flush(struct dm_target *ti, pgoff_t pgoff, void *addr, return; dax_flush(dax_dev, pgoff, addr, size); } +#else +#define stripe_dax_direct_access NULL +#define stripe_dax_copy_from_iter NULL +#define stripe_dax_flush NULL +#endif /* * Stripe status: diff --git a/drivers/md/dm.c b/drivers/md/dm.c index 2edbcc2d7d3f..70fa48f4d3a3 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -1713,7 +1713,7 @@ static void cleanup_mapped_device(struct mapped_device *md) static struct mapped_device *alloc_dev(int minor) { int r, numa_node_id = dm_get_numa_node(); - struct dax_device *dax_dev; + struct dax_device *dax_dev = NULL; struct mapped_device *md; void *old_md; @@ -1779,9 +1779,11 @@ static struct mapped_device *alloc_dev(int minor) md->disk->private_data = md; sprintf(md->disk->disk_name, "dm-%d", minor); - dax_dev = alloc_dax(md, md->disk->disk_name, &dm_dax_ops); - if (!dax_dev) - goto bad; + if (IS_ENABLED(CONFIG_DAX)) { + dax_dev = alloc_dax(md, md->disk->disk_name, &dm_dax_ops); + if (!dax_dev) + goto bad; + } md->dax_dev = dax_dev; add_disk(md->disk); diff --git a/include/linux/dax.h b/include/linux/dax.h index eb0bff6f1eab..59575b8e638e 100644 --- a/include/linux/dax.h +++ b/include/linux/dax.h @@ -27,16 +27,39 @@ extern struct attribute_group dax_attribute_group; #if IS_ENABLED(CONFIG_DAX) struct dax_device *dax_get_by_host(const char *host); +struct dax_device *alloc_dax(void *private, const char *host, + const struct dax_operations *ops); void put_dax(struct dax_device *dax_dev); +void kill_dax(struct dax_device *dax_dev); +void dax_write_cache(struct dax_device *dax_dev, bool wc); +bool dax_write_cache_enabled(struct dax_device *dax_dev); #else static inline struct dax_device *dax_get_by_host(const char *host) { return NULL; } - +static inline struct dax_device *alloc_dax(void *private, const char *host, + const struct dax_operations *ops) +{ + /* + * Callers should check IS_ENABLED(CONFIG_DAX) to know if this + * NULL is an error or expected. + */ + return NULL; +} static inline void put_dax(struct dax_device *dax_dev) { } +static inline void kill_dax(struct dax_device *dax_dev) +{ +} +static inline void dax_write_cache(struct dax_device *dax_dev, bool wc) +{ +} +static inline bool dax_write_cache_enabled(struct dax_device *dax_dev) +{ + return false; +} #endif int bdev_dax_pgoff(struct block_device *, sector_t, size_t, pgoff_t *pgoff); @@ -75,10 +98,7 @@ static inline void fs_put_dax(struct dax_device *dax_dev) int dax_read_lock(void); void dax_read_unlock(int id); -struct dax_device *alloc_dax(void *private, const char *host, - const struct dax_operations *ops); bool dax_alive(struct dax_device *dax_dev); -void kill_dax(struct dax_device *dax_dev); void *dax_get_private(struct dax_device *dax_dev); long dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff, long nr_pages, void **kaddr, pfn_t *pfn); @@ -86,8 +106,6 @@ size_t dax_copy_from_iter(struct dax_device *dax_dev, pgoff_t pgoff, void *addr, size_t bytes, struct iov_iter *i); void dax_flush(struct dax_device *dax_dev, pgoff_t pgoff, void *addr, size_t size); -void dax_write_cache(struct dax_device *dax_dev, bool wc); -bool dax_write_cache_enabled(struct dax_device *dax_dev); ssize_t dax_iomap_rw(struct kiocb *iocb, struct iov_iter *iter, const struct iomap_ops *ops); ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH v3 2/2] dm: allow device-mapper to operate without dax support 2017-08-02 17:58 ` Dan Williams @ 2017-09-11 14:41 ` Mike Snitzer -1 siblings, 0 replies; 17+ messages in thread From: Mike Snitzer @ 2017-09-11 14:41 UTC (permalink / raw) To: Dan Williams Cc: kbuild test robot, linux-nvdimm, linux-kernel, dm-devel, Bart Van Assche, Alasdair Kergon On Wed, Aug 02 2017 at 1:58pm -0400, Dan Williams <dan.j.williams@intel.com> wrote: > Rather than have device-mapper directly 'select DAX', let the fact that > BLK_DEV_PMEM selects dax act as a gate for the device-mapper dax > support. We arrange for all the dax core routines to compile to nops > when CONFIG_DAX=n. With that in place we can simply handle the > alloc_dax() error as expected and ifdef out the other device-mapper-dax > support code. > > Now, if dax is provided by a leaf driver that driver may only arrange to > compile the dax core as a module. Since device-mapper dax support is > consumed by the always-built-in portion of the device-mapper > implementation we need to upgrade from DAX=m to DAX=y. I applied the patches and then got nervous once I dug in.. this last paragraph makes little sense to me. "the always-built-in portion of the device-mapper implementation" is why: DM core can happily be compiled as a module (dm-mod.ko). And I'm not sure why you're referencing DAX related drivers/md/dm-builtin.c, why are you attachd DM's DAX support to that? I'm not seeing where that is actually happening. I don't see why DM's support for DAX would need to force DAX to be builtin rather than just a module. Sorry I didn't get around to looking at this until now, but it seems you went wrong along the way? Or maybe I'm just missing something? Mike _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 2/2] dm: allow device-mapper to operate without dax support @ 2017-09-11 14:41 ` Mike Snitzer 0 siblings, 0 replies; 17+ messages in thread From: Mike Snitzer @ 2017-09-11 14:41 UTC (permalink / raw) To: Dan Williams Cc: kbuild test robot, linux-nvdimm, linux-kernel, dm-devel, Bart Van Assche, Alasdair Kergon On Wed, Aug 02 2017 at 1:58pm -0400, Dan Williams <dan.j.williams@intel.com> wrote: > Rather than have device-mapper directly 'select DAX', let the fact that > BLK_DEV_PMEM selects dax act as a gate for the device-mapper dax > support. We arrange for all the dax core routines to compile to nops > when CONFIG_DAX=n. With that in place we can simply handle the > alloc_dax() error as expected and ifdef out the other device-mapper-dax > support code. > > Now, if dax is provided by a leaf driver that driver may only arrange to > compile the dax core as a module. Since device-mapper dax support is > consumed by the always-built-in portion of the device-mapper > implementation we need to upgrade from DAX=m to DAX=y. I applied the patches and then got nervous once I dug in.. this last paragraph makes little sense to me. "the always-built-in portion of the device-mapper implementation" is why: DM core can happily be compiled as a module (dm-mod.ko). And I'm not sure why you're referencing DAX related drivers/md/dm-builtin.c, why are you attachd DM's DAX support to that? I'm not seeing where that is actually happening. I don't see why DM's support for DAX would need to force DAX to be builtin rather than just a module. Sorry I didn't get around to looking at this until now, but it seems you went wrong along the way? Or maybe I'm just missing something? Mike ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 2/2] dm: allow device-mapper to operate without dax support 2017-09-11 14:41 ` Mike Snitzer (?) @ 2017-09-11 15:56 ` Dan Williams -1 siblings, 0 replies; 17+ messages in thread From: Dan Williams @ 2017-09-11 15:56 UTC (permalink / raw) To: Mike Snitzer Cc: kbuild test robot, linux-nvdimm, linux-kernel, dm-devel, Bart Van Assche, Alasdair Kergon On Mon, Sep 11, 2017 at 7:41 AM, Mike Snitzer <snitzer@redhat.com> wrote: > On Wed, Aug 02 2017 at 1:58pm -0400, > Dan Williams <dan.j.williams@intel.com> wrote: > >> Rather than have device-mapper directly 'select DAX', let the fact that >> BLK_DEV_PMEM selects dax act as a gate for the device-mapper dax >> support. We arrange for all the dax core routines to compile to nops >> when CONFIG_DAX=n. With that in place we can simply handle the >> alloc_dax() error as expected and ifdef out the other device-mapper-dax >> support code. >> >> Now, if dax is provided by a leaf driver that driver may only arrange to >> compile the dax core as a module. Since device-mapper dax support is >> consumed by the always-built-in portion of the device-mapper >> implementation we need to upgrade from DAX=m to DAX=y. > > I applied the patches and then got nervous once I dug in.. this last > paragraph makes little sense to me. "the always-built-in portion of the > device-mapper implementation" is why: DM core can happily be compiled as > a module (dm-mod.ko). > > And I'm not sure why you're referencing DAX related > drivers/md/dm-builtin.c, why are you attachd DM's DAX support to that? > I'm not seeing where that is actually happening. > > I don't see why DM's support for DAX would need to force DAX to be > builtin rather than just a module. > > Sorry I didn't get around to looking at this until now, but it seems you > went wrong along the way? Or maybe I'm just missing something? > No, my fault, I didn't track BLK_DEV_DM_BUILTIN correctly and we can safely make DAX a module when CONFIG_BLK_DEV_DM=m. I'll fix that up, thanks for the catch. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 2/2] dm: allow device-mapper to operate without dax support @ 2017-09-11 15:56 ` Dan Williams 0 siblings, 0 replies; 17+ messages in thread From: Dan Williams @ 2017-09-11 15:56 UTC (permalink / raw) To: Mike Snitzer Cc: kbuild test robot, linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, linux-kernel-u79uwXL29TY76Z2rM5mHXA, dm-devel-H+wXaHxf7aLQT0dZR+AlfA, Bart Van Assche, Alasdair Kergon On Mon, Sep 11, 2017 at 7:41 AM, Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote: > On Wed, Aug 02 2017 at 1:58pm -0400, > Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote: > >> Rather than have device-mapper directly 'select DAX', let the fact that >> BLK_DEV_PMEM selects dax act as a gate for the device-mapper dax >> support. We arrange for all the dax core routines to compile to nops >> when CONFIG_DAX=n. With that in place we can simply handle the >> alloc_dax() error as expected and ifdef out the other device-mapper-dax >> support code. >> >> Now, if dax is provided by a leaf driver that driver may only arrange to >> compile the dax core as a module. Since device-mapper dax support is >> consumed by the always-built-in portion of the device-mapper >> implementation we need to upgrade from DAX=m to DAX=y. > > I applied the patches and then got nervous once I dug in.. this last > paragraph makes little sense to me. "the always-built-in portion of the > device-mapper implementation" is why: DM core can happily be compiled as > a module (dm-mod.ko). > > And I'm not sure why you're referencing DAX related > drivers/md/dm-builtin.c, why are you attachd DM's DAX support to that? > I'm not seeing where that is actually happening. > > I don't see why DM's support for DAX would need to force DAX to be > builtin rather than just a module. > > Sorry I didn't get around to looking at this until now, but it seems you > went wrong along the way? Or maybe I'm just missing something? > No, my fault, I didn't track BLK_DEV_DM_BUILTIN correctly and we can safely make DAX a module when CONFIG_BLK_DEV_DM=m. I'll fix that up, thanks for the catch. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 2/2] dm: allow device-mapper to operate without dax support @ 2017-09-11 15:56 ` Dan Williams 0 siblings, 0 replies; 17+ messages in thread From: Dan Williams @ 2017-09-11 15:56 UTC (permalink / raw) To: Mike Snitzer Cc: kbuild test robot, linux-nvdimm, linux-kernel, dm-devel, Bart Van Assche, Alasdair Kergon On Mon, Sep 11, 2017 at 7:41 AM, Mike Snitzer <snitzer@redhat.com> wrote: > On Wed, Aug 02 2017 at 1:58pm -0400, > Dan Williams <dan.j.williams@intel.com> wrote: > >> Rather than have device-mapper directly 'select DAX', let the fact that >> BLK_DEV_PMEM selects dax act as a gate for the device-mapper dax >> support. We arrange for all the dax core routines to compile to nops >> when CONFIG_DAX=n. With that in place we can simply handle the >> alloc_dax() error as expected and ifdef out the other device-mapper-dax >> support code. >> >> Now, if dax is provided by a leaf driver that driver may only arrange to >> compile the dax core as a module. Since device-mapper dax support is >> consumed by the always-built-in portion of the device-mapper >> implementation we need to upgrade from DAX=m to DAX=y. > > I applied the patches and then got nervous once I dug in.. this last > paragraph makes little sense to me. "the always-built-in portion of the > device-mapper implementation" is why: DM core can happily be compiled as > a module (dm-mod.ko). > > And I'm not sure why you're referencing DAX related > drivers/md/dm-builtin.c, why are you attachd DM's DAX support to that? > I'm not seeing where that is actually happening. > > I don't see why DM's support for DAX would need to force DAX to be > builtin rather than just a module. > > Sorry I didn't get around to looking at this until now, but it seems you > went wrong along the way? Or maybe I'm just missing something? > No, my fault, I didn't track BLK_DEV_DM_BUILTIN correctly and we can safely make DAX a module when CONFIG_BLK_DEV_DM=m. I'll fix that up, thanks for the catch. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 0/2] dax, dm: stop requiring dax for device-mapper 2017-08-02 17:57 ` Dan Williams (?) @ 2017-08-02 18:55 ` Mike Snitzer -1 siblings, 0 replies; 17+ messages in thread From: Mike Snitzer @ 2017-08-02 18:55 UTC (permalink / raw) To: Dan Williams Cc: kbuild test robot, linux-nvdimm, Michael Ellerman, Heiko Carstens, linux-kernel, Bart Van Assche, dm-devel, Paul Mackerras, Gerald Schaefer, Benjamin Herrenschmidt, Martin Schwidefsky, Alasdair Kergon On Wed, Aug 02 2017 at 1:57pm -0400, Dan Williams <dan.j.williams@intel.com> wrote: > Changes since v2 [1]: > * rebase on -next to integrate with commit 273752c9ff03 "dm, dax: Make > sure dm_dax_flush() is called if device supports it" (kbuild robot) > * fix CONFIG_DAX dependencies to upgrade CONFIG_DAX=m to CONFIG_DAX=y > (kbuild robot) > > [1]: https://www.spinics.net/lists/kernel/msg2570522.html > > --- > > Bart points out that the DAX core is unconditionally enabled if > device-mapper is enabled. Add some config machinery and some > stub-static-inline routines to allow dax infrastructure to be deleted > from device-mapper at compile time. > > Since this depends on commit 273752c9ff03 that's already in -next, this > should go through the device-mapper tree. Commit 273752c9ff03eb83856601b2a3458218bb949e46 is upstream as of v4.13-rc3 -- so no real need to have this go via linux-dm.git That said, I don't mind picking it up once we are satisfied with the implementation. I'll start reviewing shortly. Mike _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 0/2] dax, dm: stop requiring dax for device-mapper @ 2017-08-02 18:55 ` Mike Snitzer 0 siblings, 0 replies; 17+ messages in thread From: Mike Snitzer @ 2017-08-02 18:55 UTC (permalink / raw) To: Dan Williams Cc: kbuild test robot, linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Michael Ellerman, Heiko Carstens, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Bart Van Assche, dm-devel-H+wXaHxf7aLQT0dZR+AlfA, Paul Mackerras, Gerald Schaefer, Benjamin Herrenschmidt, Martin Schwidefsky, Alasdair Kergon On Wed, Aug 02 2017 at 1:57pm -0400, Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote: > Changes since v2 [1]: > * rebase on -next to integrate with commit 273752c9ff03 "dm, dax: Make > sure dm_dax_flush() is called if device supports it" (kbuild robot) > * fix CONFIG_DAX dependencies to upgrade CONFIG_DAX=m to CONFIG_DAX=y > (kbuild robot) > > [1]: https://www.spinics.net/lists/kernel/msg2570522.html > > --- > > Bart points out that the DAX core is unconditionally enabled if > device-mapper is enabled. Add some config machinery and some > stub-static-inline routines to allow dax infrastructure to be deleted > from device-mapper at compile time. > > Since this depends on commit 273752c9ff03 that's already in -next, this > should go through the device-mapper tree. Commit 273752c9ff03eb83856601b2a3458218bb949e46 is upstream as of v4.13-rc3 -- so no real need to have this go via linux-dm.git That said, I don't mind picking it up once we are satisfied with the implementation. I'll start reviewing shortly. Mike ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 0/2] dax, dm: stop requiring dax for device-mapper @ 2017-08-02 18:55 ` Mike Snitzer 0 siblings, 0 replies; 17+ messages in thread From: Mike Snitzer @ 2017-08-02 18:55 UTC (permalink / raw) To: Dan Williams Cc: kbuild test robot, linux-nvdimm, Michael Ellerman, Heiko Carstens, linux-kernel, Martin Schwidefsky, dm-devel, Paul Mackerras, Alasdair Kergon, Benjamin Herrenschmidt, Bart Van Assche, Gerald Schaefer On Wed, Aug 02 2017 at 1:57pm -0400, Dan Williams <dan.j.williams@intel.com> wrote: > Changes since v2 [1]: > * rebase on -next to integrate with commit 273752c9ff03 "dm, dax: Make > sure dm_dax_flush() is called if device supports it" (kbuild robot) > * fix CONFIG_DAX dependencies to upgrade CONFIG_DAX=m to CONFIG_DAX=y > (kbuild robot) > > [1]: https://www.spinics.net/lists/kernel/msg2570522.html > > --- > > Bart points out that the DAX core is unconditionally enabled if > device-mapper is enabled. Add some config machinery and some > stub-static-inline routines to allow dax infrastructure to be deleted > from device-mapper at compile time. > > Since this depends on commit 273752c9ff03 that's already in -next, this > should go through the device-mapper tree. Commit 273752c9ff03eb83856601b2a3458218bb949e46 is upstream as of v4.13-rc3 -- so no real need to have this go via linux-dm.git That said, I don't mind picking it up once we are satisfied with the implementation. I'll start reviewing shortly. Mike ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 0/2] dax, dm: stop requiring dax for device-mapper 2017-08-02 18:55 ` Mike Snitzer @ 2017-09-09 18:56 ` Dan Williams -1 siblings, 0 replies; 17+ messages in thread From: Dan Williams @ 2017-09-09 18:56 UTC (permalink / raw) To: Mike Snitzer Cc: kbuild test robot, linux-nvdimm, Michael Ellerman, Heiko Carstens, linux-kernel, Bart Van Assche, dm-devel, Paul Mackerras, Gerald Schaefer, Benjamin Herrenschmidt, Martin Schwidefsky, Mikulas Patocka, Alasdair Kergon On Wed, Aug 2, 2017 at 11:55 AM, Mike Snitzer <snitzer@redhat.com> wrote: > On Wed, Aug 02 2017 at 1:57pm -0400, > Dan Williams <dan.j.williams@intel.com> wrote: > >> Changes since v2 [1]: >> * rebase on -next to integrate with commit 273752c9ff03 "dm, dax: Make >> sure dm_dax_flush() is called if device supports it" (kbuild robot) >> * fix CONFIG_DAX dependencies to upgrade CONFIG_DAX=m to CONFIG_DAX=y >> (kbuild robot) >> >> [1]: https://www.spinics.net/lists/kernel/msg2570522.html >> >> --- >> >> Bart points out that the DAX core is unconditionally enabled if >> device-mapper is enabled. Add some config machinery and some >> stub-static-inline routines to allow dax infrastructure to be deleted >> from device-mapper at compile time. >> >> Since this depends on commit 273752c9ff03 that's already in -next, this >> should go through the device-mapper tree. > > Commit 273752c9ff03eb83856601b2a3458218bb949e46 is upstream as of > v4.13-rc3 -- so no real need to have this go via linux-dm.git > > That said, I don't mind picking it up once we are satisfied with the > implementation. I'll start reviewing shortly. Hi Mike, Friendly reminder about this cleanup... _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 0/2] dax, dm: stop requiring dax for device-mapper @ 2017-09-09 18:56 ` Dan Williams 0 siblings, 0 replies; 17+ messages in thread From: Dan Williams @ 2017-09-09 18:56 UTC (permalink / raw) To: Mike Snitzer Cc: kbuild test robot, linux-nvdimm, Michael Ellerman, Heiko Carstens, linux-kernel, Martin Schwidefsky, dm-devel, Paul Mackerras, Alasdair Kergon, Benjamin Herrenschmidt, Bart Van Assche, Gerald Schaefer, Mikulas Patocka On Wed, Aug 2, 2017 at 11:55 AM, Mike Snitzer <snitzer@redhat.com> wrote: > On Wed, Aug 02 2017 at 1:57pm -0400, > Dan Williams <dan.j.williams@intel.com> wrote: > >> Changes since v2 [1]: >> * rebase on -next to integrate with commit 273752c9ff03 "dm, dax: Make >> sure dm_dax_flush() is called if device supports it" (kbuild robot) >> * fix CONFIG_DAX dependencies to upgrade CONFIG_DAX=m to CONFIG_DAX=y >> (kbuild robot) >> >> [1]: https://www.spinics.net/lists/kernel/msg2570522.html >> >> --- >> >> Bart points out that the DAX core is unconditionally enabled if >> device-mapper is enabled. Add some config machinery and some >> stub-static-inline routines to allow dax infrastructure to be deleted >> from device-mapper at compile time. >> >> Since this depends on commit 273752c9ff03 that's already in -next, this >> should go through the device-mapper tree. > > Commit 273752c9ff03eb83856601b2a3458218bb949e46 is upstream as of > v4.13-rc3 -- so no real need to have this go via linux-dm.git > > That said, I don't mind picking it up once we are satisfied with the > implementation. I'll start reviewing shortly. Hi Mike, Friendly reminder about this cleanup... ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2017-09-11 15:56 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-08-02 17:57 [PATCH v3 0/2] dax, dm: stop requiring dax for device-mapper Dan Williams 2017-08-02 17:57 ` Dan Williams 2017-08-02 17:58 ` [PATCH v3 1/2] dax: introduce CONFIG_DAX_DRIVER Dan Williams 2017-08-02 17:58 ` Dan Williams 2017-08-02 17:58 ` Dan Williams 2017-08-02 17:58 ` [PATCH v3 2/2] dm: allow device-mapper to operate without dax support Dan Williams 2017-08-02 17:58 ` Dan Williams 2017-09-11 14:41 ` Mike Snitzer 2017-09-11 14:41 ` Mike Snitzer 2017-09-11 15:56 ` Dan Williams 2017-09-11 15:56 ` Dan Williams 2017-09-11 15:56 ` Dan Williams 2017-08-02 18:55 ` [PATCH v3 0/2] dax, dm: stop requiring dax for device-mapper Mike Snitzer 2017-08-02 18:55 ` Mike Snitzer 2017-08-02 18:55 ` Mike Snitzer 2017-09-09 18:56 ` Dan Williams 2017-09-09 18:56 ` Dan Williams
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.