[dm-devel] [RFC] using #pragma push_macro and pop_macro

There is an argument for using these #pragmas for pr_fmt. gcc/clang/icc all support push_macro and pop_macro pragmas. As far as I can tell, these compilers are the only ones used to compile the kernel. Anyone have any objection to using these pragmas? On Tue, 2017-04-18 at 05:02 +0800, kbuild

[dm-devel] [PATCH] multipath-tools: Replace multipath configuration output

Cc: Christophe Varoqui Cc: device-mapper development Signed-off-by: Xose Vazquez Perez --- libmultipath/propsel.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libmultipath/propsel.c

Re: [dm-devel] [PATCH] device-mapper: Convert printks to pr_ macros

Hi Joe, [auto build test ERROR on v4.9-rc8] [also build test ERROR on next-20170413] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[dm-devel] [resend PATCH v2 33/33] libnvdimm, pmem: disable dax flushing when pmem is fronting a volatile region

The pmem driver attaches to both persistent and volatile memory ranges advertised by the ACPI NFIT. When the region is volatile it is redundant to spend cycles flushing caches at fsync(). Check if the hosting region is volatile and do not set QUEUE_FLAG_WC if it is. Cc: Jan Kara

[dm-devel] [resend PATCH v2 30/33] libnvdimm, pmem: fix persistence warning

The pmem driver assumes if platform firmware describes the memory devices associated with a persistent memory range and CONFIG_ARCH_HAS_PMEM_API=y that it has all the mechanism necessary to flush data to a power-fail safe zone. We warn if the firmware does not describe memory devices, but we also

[dm-devel] [resend PATCH v2 28/33] x86, libnvdimm, dax: stop abusing __copy_user_nocache

The pmem and nd_blk drivers both have need to copy data through the cpu cache to persistent memory. To date they have been abusing __copy_user_nocache through the memcpy_to_pmem abstraction, but this has several problems: * __copy_user_nocache does not guarantee that it will always avoid the

[dm-devel] [resend PATCH v2 32/33] filesystem-dax: gate calls to dax_flush() on QUEUE_FLAG_WC

Some platforms arrange for cpu caches to be flushed on power-fail. On those platforms there is no requirement that the kernel track and flush potentially dirty cache lines. Given that we still insert entries into the radix for locking purposes this patch only disables the cache flush loop, not the

[dm-devel] [resend PATCH v2 31/33] libnvdimm, nfit: enable support for volatile ranges

Allow volatile nfit ranges to participate in all the same infrastructure provided for persistent memory regions. A resulting resulting namespace device will still be called "pmem", but the parent region type will be "nd_volatile". This is in preparation for disabling the dax ->flush() operation in

[dm-devel] [resend PATCH v2 29/33] uio, libnvdimm, pmem: implement cache bypass for all copy_from_iter() operations

Introduce copy_from_iter_ops() to enable passing custom sub-routines to iterate_and_advance(). Define pmem operations that guarantee cache bypass to supplement the existing usage of __copy_from_iter_nocache() backed by arch_wb_cache_pmem(). Cc: Jan Kara Cc: Jeff Moyer

[dm-devel] [resend PATCH v2 22/33] dax, pmem: introduce an optional 'flush' dax_operation

Filesystem-DAX flushes caches whenever it writes to the address returned through dax_direct_access() and when writing back dirty radix entries. That flushing is only required in the pmem case, so add a dax operation to allow pmem to take this extra action, but skip it for other dax capable devices

[dm-devel] [resend PATCH v2 24/33] filesystem-dax: convert to dax_flush()

Filesystem-DAX flushes caches whenever it writes to the address returned through dax_direct_access() and when writing back dirty radix entries. That flushing is only required in the pmem case, so the dax_flush() helper skips cache management work when the underlying driver does not specify a flush

[dm-devel] [resend PATCH v2 27/33] x86, libnvdimm, pmem: move arch_invalidate_pmem() to libnvdimm

Kill this globally defined wrapper and move to libnvdimm so that we can ultimately remove the public pmem api. Cc: Cc: Jan Kara Cc: Jeff Moyer Cc: Ingo Molnar Cc: Christoph Hellwig Cc: "H. Peter Anvin"

[dm-devel] [resend PATCH v2 25/33] x86, dax: replace clear_pmem() with open coded memset + dax_ops->flush

The clear_pmem() helper simply combines a memset() plus a cache flush. Now that the flush routine is optionally provided by the dax device driver we can avoid unnecessary cache management on dax devices fronting volatile memory. With clear_pmem() gone we can follow on with a patch to make pmem

[dm-devel] [resend PATCH v2 26/33] x86, dax, libnvdimm: move wb_cache_pmem() to libnvdimm

With all calls to this routine re-directed through the pmem driver, we can kill the pmem api indirection. arch_wb_cache_pmem() is now optionally supplied by an arch specific extension to libnvdimm. Same as before, pmem flushing is only defined for x86_64, but it is straightforward to add other

[dm-devel] [resend PATCH v2 23/33] dm: add ->flush() dax operation support

Allow device-mapper to route flush operations to the per-target implementation. In order for the device stacking to work we need a dax_dev and a pgoff relative to that device. This gives each layer of the stack the information it needs to look up the operation pointer for the next level. This

[dm-devel] [resend PATCH v2 18/33] x86, dax, pmem: remove indirection around memcpy_from_pmem()

memcpy_from_pmem() maps directly to memcpy_mcsafe(). The wrapper serves no real benefit aside from affording a more generic function name than the x86-specific 'mcsafe'. However this would not be the first time that x86 terminology leaked into the global namespace. For lack of better name, just

[dm-devel] [resend PATCH v2 21/33] filesystem-dax: convert to dax_copy_from_iter()

Now that all possible providers of the dax_operations copy_from_iter method are implemented, switch filesytem-dax to call the driver rather than copy_to_iter_pmem. Signed-off-by: Dan Williams --- arch/x86/include/asm/pmem.h | 50

[dm-devel] [resend PATCH v2 16/33] block, dax: convert bdev_dax_supported() to dax_direct_access()

Kill of the final user of bdev_direct_access() and struct blk_dax_ctl. Signed-off-by: Dan Williams --- fs/block_dev.c | 48 1 file changed, 28 insertions(+), 20 deletions(-) diff --git a/fs/block_dev.c

[dm-devel] [resend PATCH v2 20/33] dm: add ->copy_from_iter() dax operation support

Allow device-mapper to route copy_from_iter operations to the per-target implementation. In order for the device stacking to work we need a dax_dev and a pgoff relative to that device. This gives each layer of the stack the information it needs to look up the operation pointer for the next level.

[dm-devel] [resend PATCH v2 19/33] dax, pmem: introduce 'copy_from_iter' dax operation

The direct-I/O write path for a pmem device must ensure that data is flushed to a power-fail safe zone when the operation is complete. However, other dax capable block devices, like brd, do not have this requirement. Introduce a 'copy_from_iter' dax operation so that pmem can inject cache

[dm-devel] [resend PATCH v2 15/33] filesystem-dax: convert to dax_direct_access()

Now that a dax_device is plumbed through all dax-capable drivers we can switch from block_device_operations to dax_operations for invoking ->direct_access. This also lets us kill off some usages of struct blk_dax_ctl on the way to its eventual removal. Suggested-by: Christoph Hellwig

[dm-devel] [resend PATCH v2 12/33] dm: teach dm-targets to use a dax_device + dax_operations

Arrange for dm to lookup the dax services available from member devices. Update the dax-capable targets, linear and stripe, to route dax operations to the underlying device. Changes the target-internal ->direct_access() method to more closely align with the dax_operations ->direct_access() calling

[dm-devel] [resend PATCH v2 14/33] Revert "block: use DAX for partition table reads"

commit d1a5f2b4d8a1 ("block: use DAX for partition table reads") was part of a stalled effort to allow dax mappings of block devices. Since then the device-dax mechanism has filled the role of dax-mapping static device ranges. Now that we are moving ->direct_access() from a block_device operation

[dm-devel] [resend PATCH v2 07/33] brd: add dax_operations support

Setup a dax_inode to have the same lifetime as the brd block device and add a ->direct_access() method that is equivalent to brd_direct_access(). Once fs/dax.c has been converted to use dax_operations the old brd_direct_access() will be removed. Signed-off-by: Dan Williams

[dm-devel] [resend PATCH v2 09/33] block: kill bdev_dax_capable()

This is leftover dead code that has since been replaced by bdev_dax_supported(). Signed-off-by: Dan Williams --- fs/block_dev.c | 24 include/linux/blkdev.h |1 - 2 files changed, 25 deletions(-) diff --git a/fs/block_dev.c

[dm-devel] [resend PATCH v2 08/33] dcssblk: add dax_operations support

Setup a dax_dev to have the same lifetime as the dcssblk block device and add a ->direct_access() method that is equivalent to dcssblk_direct_access(). Once fs/dax.c has been converted to use dax_operations the old dcssblk_direct_access() will be removed. Cc: Gerald Schaefer

[dm-devel] [resend PATCH v2 05/33] pmem: add dax_operations support

Setup a dax_device to have the same lifetime as the pmem block device and add a ->direct_access() method that is equivalent to pmem_direct_access(). Once fs/dax.c has been converted to use dax_operations the old pmem_direct_access() will be removed. Signed-off-by: Dan Williams

[dm-devel] [resend PATCH v2 04/33] dax: introduce dax_operations

Track a set of dax_operations per dax_device that can be set at alloc_dax() time. These operations will be used to stop the abuse of block_device_operations for communicating dax capabilities to filesystems. It will also be used to replace the "pmem api" and move pmem-specific cache maintenance,

[dm-devel] [resend PATCH v2 03/33] dax: add a facility to lookup a dax device by 'host' device name

For the current block_device based filesystem-dax path, we need a way for it to lookup the dax_device associated with a block_device. Add a 'host' property of a dax_device that can be used for this purpose. It is a free form string, but for a dax_device associated with a block device it is the

[dm-devel] [resend PATCH v2 02/33] dax: refactor dax-fs into a generic provider of 'struct dax_device' instances

We want dax capable drivers to be able to publish a set of dax operations [1]. However, we do not want to further abuse block_devices to advertise these operations. Instead we will attach these operations to a dax device and add a lookup mechanism to go from block device path to a dax device. A

[dm-devel] [resend PATCH v2 01/33] device-dax: rename 'dax_dev' to 'dev_dax'

In preparation for introducing a struct dax_device type to the kernel global type namespace, rename dax_dev to dev_dax. A 'dax_device' instance will be a generic device-driver object for any provider of dax functionality. A 'dev_dax' object is a device-dax-driver local / internal instance.

[dm-devel] [resend PATCH v2 00/33] dax: introduce dax_operations

[ resend to add dm-devel, linux-block, and fs-devel, apologies for the duplicates ] Changes since v1 [1] and the dax-fs RFC [2]: * rename struct dax_inode to struct dax_device (Christoph) * rewrite arch_memcpy_to_pmem() in C with inline asm * use QUEUE_FLAG_WC to gate dax cache management (Jeff)

[dm-devel] [PATCH] device-mapper: Convert printks to pr_ macros

Using pr_ is the more common logging style. In addition, using the pr_ macros could shrink the kernel image if/when the macros are converted to functions. Miscellanea: o Standardize style and use pr_fmt to prefix the output o Standardize the DMDEBUG and DMDEBUG_LIMIT output prefix

Re: [dm-devel] [PATCH 02/25] block: remove the blk_execute_rq return value

On 04/14/2017 02:22 AM, h...@lst.de wrote: > On Thu, Apr 13, 2017 at 08:03:22PM +, Bart Van Assche wrote: >> That blk_execute_rq() call can only be reached if a few lines above 0 was >> assigned to the "error" variable. Since nfsd4_scsi_identify_device() returns >> the value of the "error"