[RFC PATCH] scsi, block: fix duplicate bdi name registration crashes

Warnings of the following form occur because scsi reuses a devt number while the block layer still has it referenced as the name of the bdi [1]: WARNING: CPU: 1 PID: 93 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 sysfs: cannot create duplicate filename '/devices/virtual/bdi/8:192' [..] Call

[PATCH V3 1/1] percpu-refcount: fix reference leak during percpu-atomic transition

percpu_ref_tryget() and percpu_ref_tryget_live() should return "true" IFF they acquire a reference. But the return value from atomic_long_inc_not_zero() is a long and may have high bits set, e.g. PERCPU_COUNT_BIAS, and the return value of the tryget routines is bool so the reference may actually

Re: [PATCH V3 1/1] percpu-refcount: fix reference leak during percpu-atomic transition

On Sat, Jan 28, 2017 at 06:42:20AM -0600, Douglas Miller wrote: > percpu_ref_tryget() and percpu_ref_tryget_live() should return > "true" IFF they acquire a reference. But the return value from > atomic_long_inc_not_zero() is a long and may have high bits set, > e.g. PERCPU_COUNT_BIAS, and the

[RFC PATCH 04/17] dax: introduce dax_operations

Track a set of dax_operations per dax_inode that can be set at alloc_dax_inode() 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

[RFC PATCH 13/17] fs: update mount_bdev() to lookup dax infrastructure

This is in preparation for removing the ->direct_access() method from block_device_operations. Signed-off-by: Dan Williams --- fs/block_dev.c |6 -- fs/super.c | 32 +--- include/linux/fs.h |1 + 3 files changed, 34

[RFC PATCH 15/17] 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

[RFC PATCH 10/17] block: introduce bdev_dax_direct_access()

Provide a replacement for bdev_direct_access() that uses dax_operations.direct_access() instead of block_device_operations.direct_access(). Once all consumers of the old api have been converted bdev_direct_access() will be deleted. Given that block device partitioning decisions can cause dax page

[RFC PATCH 05/17] pmem: add dax_operations support

Setup a dax_inode 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

[RFC PATCH 09/17] 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

[RFC PATCH 08/17] dcssblk: add dax_operations support

Setup a dax_inode 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. Signed-off-by: Dan Williams

[RFC PATCH 07/17] 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

[RFC PATCH 06/17] axon_ram: add dax_operations support

Setup a dax_inode to have the same lifetime as the axon_ram block device and add a ->direct_access() method that is equivalent to axon_ram_direct_access(). Once fs/dax.c has been converted to use dax_operations the old axon_ram_direct_access() will be removed. --- arch/powerpc/platforms/Kconfig |

[RFC PATCH 11/17] dm: add dax_operations support (producer)

Setup a dax_inode to have the same lifetime as the dm block device and add a ->direct_access() method that is equivalent to dm_blk_direct_access(). Once fs/dax.c has been converted to use dax_operations the old dm_blk_direct_access() will be removed. This enabling is only for the top-level dm

[RFC PATCH 16/17] fs, dax: convert filesystem-dax to bdev_dax_direct_access

Now that a dax_inode is plumbed through all dax-capable drivers we can switch from block_device_operations to dax_operations for invoking ->direct_access. Signed-off-by: Dan Williams --- fs/dax.c| 143 +++

[RFC PATCH 14/17] ext2, ext4, xfs: retrieve dax_inode through iomap operations

In preparation for converting fs/dax.c to use bdev_dax_direct_access() instead of bdev_direct_access(), add the plumbing to retrieve the dax_inode determined at mount through ->iomap_begin. Signed-off-by: Dan Williams --- fs/ext2/inode.c |1 + fs/ext4/inode.c

[RFC PATCH 12/17] dm: add dax_operations support (consumer)

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. Signed-off-by: Dan Williams --- drivers/md/dm-linear.c| 24

[RFC PATCH 17/17] block: remove block_device_operations.direct_access and related infrastructure

Now that all the producers and consumers of dax interfaces have been converted to using dax_operations on a dax_inode, remove the block device direct_access enabling. Signed-off-by: Dan Williams --- arch/powerpc/sysdev/axonram.c | 15 --

[RFC PATCH 03/17] dax: add a facility to lookup a dax inode by 'host' device name

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

[RFC PATCH 01/17] dax: refactor dax-fs into a generic provider of dax inodes

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 inode and add a lookup mechanism to go from block device path to a dax inode. A dax

[RFC PATCH 00/17] introduce a dax_inode for dax_operations

Recently there was an effort to introduce dax_operations to unwind the abuse of the user-copy api in the pmem api [1]. Christoph noted that we should not add new block-dax operations as it is further abuse of struct block_device [2]. The ->direct_access() method in block_device_operations was an

[RFC PATCH 02/17] dax: convert dax_inode locking to srcu

In preparation for adding dax_operations that perform ->direct_access() and user copy operations relative to a dax_inode, convert the existing dax_inode locking to srcu. Some dax drivers need to sleep in their ->direct_access() methods and user copying may fault / sleep. Signed-off-by: Dan

Re: [PATCH 15/18] scsi: allocate scsi_cmnd structures as part of struct request

On Fri, Jan 27, 2017 at 06:39:46PM +, Bart Van Assche wrote: > Why have the scsi_release_buffers() and scsi_put_command(cmd) calls been > moved up? I haven't found an explanation for this change in the patch > description. Because they reference the scsi_cmnd, which are now part of the

Re: split scsi passthrough fields out of struct request V2

On Fri, Jan 27, 2017 at 09:27:53PM +, Bart Van Assche wrote: > Have you considered to convert all block drivers to the new > approach and to get rid of request.special? If so, do you already > have plans to start working on this? I'm namely wondering wheter I > should start working on this

Re: split scsi passthrough fields out of struct request V3

On Fri, Jan 27, 2017 at 06:58:53PM +, Bart Van Assche wrote: > Version 3 of the patch with title "block: split scsi_request out of > struct request" (commit 3c30af6ebe12) differs significantly from v2 > of that patch that has been posted on several mailing lists. E.g. v2 > moves __cmd[], cmd

Re: [PATCH 14/18] scsi: remove __scsi_alloc_queue

On Fri, Jan 27, 2017 at 05:58:02PM +, Bart Van Assche wrote: > Since __scsi_init_queue() modifies data in the Scsi_Host structure, have you > considered to add the declaration for this function to ? > If you want to keep this declaration in please add a > direct include of that header file to