user/sven/linux.git/drivers/md, branch v4.19.1

Merge tag 'alloc-args-v4.19-rc8' of https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2018-10-11T17:10:30Z

Kees writes: "Fix open-coded multiplication arguments to allocators - Fixes several new open-coded multiplications added in the 4.19 merge window." * tag 'alloc-args-v4.19-rc8' of https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: treewide: Replace more open-coded allocation size multiplications

dm linear: fix linear_end_io conditional definition

2018-10-11T03:22:24Z

The dm-linear target is independent of the dm-zoned target. For code requiring support for zoned block devices, use CONFIG_BLK_DEV_ZONED instead of CONFIG_DM_ZONED. While at it, similarly to dm linear, also enable the DM_TARGET_ZONED_HM feature in dm-flakey only if CONFIG_BLK_DEV_ZONED is defined. Fixes: beb9caac211c1 ("dm linear: eliminate linear_end_io call if CONFIG_DM_ZONED disabled") Fixes: 0be12c1c7fce7 ("dm linear: add support for zoned block devices") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Signed-off-by: Mike Snitzer

dm linear: eliminate linear_end_io call if CONFIG_DM_ZONED disabled

2018-10-10T16:11:09Z

It is best to avoid any extra overhead associated with bio completion. DM core will indirectly call a DM target's .end_io if it is defined. In the case of DM linear, there is no need to do so (for every bio that completes) if CONFIG_DM_ZONED is not enabled. Avoiding an extra indirect call for every bio completion is very important for ensuring DM linear doesn't incur more overhead that further widens the performance gap between dm-linear and raw block devices. Fixes: 0be12c1c7fce7 ("dm linear: add support for zoned block devices") Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer

dm: fix report zone remapping to account for partition offset

2018-10-09T18:20:13Z

If dm-linear or dm-flakey are layered on top of a partition of a zoned block device, remapping of the start sector and write pointer position of the zones reported by a report zones BIO must be modified to account for the target table entry mapping (start offset within the device and entry mapping with the dm device). If the target's backing device is a partition of a whole disk, the start sector on the physical device of the partition must also be accounted for when modifying the zone information. However, dm_remap_zone_report() was not considering this last case, resulting in incorrect zone information remapping with targets using disk partitions. Fix this by calculating the target backing device start sector using the position of the completed report zones BIO and the unchanged position and size of the original report zone BIO. With this value calculated, the start sector and write pointer position of the target zones can be correctly remapped. Fixes: 10999307c14e ("dm: introduce dm_remap_zone_report()") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Signed-off-by: Mike Snitzer

dm cache: destroy migration_cache if cache target registration failed

2018-10-09T17:53:03Z

Commit 7e6358d244e47 ("dm: fix various targets to dm_register_target after module __init resources created") inadvertently introduced this bug when it moved dm_register_target() after the call to KMEM_CACHE(). Fixes: 7e6358d244e47 ("dm: fix various targets to dm_register_target after module __init resources created") Cc: stable@vger.kernel.org Signed-off-by: Shenghui Wang Signed-off-by: Mike Snitzer

treewide: Replace more open-coded allocation size multiplications

2018-10-06T01:06:30Z

As done treewide earlier, this catches several more open-coded allocation size calculations that were added to the kernel during the merge window. This performs the following mechanical transformations using Coccinelle: kvmalloc(a * b, ...) -> kvmalloc_array(a, b, ...) kvzalloc(a * b, ...) -> kvcalloc(a, b, ...) devm_kzalloc(..., a * b, ...) -> devm_kcalloc(..., a, b, ...) Signed-off-by: Kees Cook

Merge tag 'for-4.19/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm

2018-10-05T23:09:56Z

Mike writes: "device mapper fixes - Fix a DM thinp __udivdi3 undefined on 32-bit bug introduced during 4.19 merge window. - Fix leak and dangling pointer in DM multipath's scsi_dh related code. - A couple stable@ fixes for DM cache's resize support. - A DM raid fix to remove "const" from decipher_sync_action()'s return type." * tag 'for-4.19/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm cache: fix resize crash if user doesn't reload cache table dm cache metadata: ignore hints array being too small during resize dm raid: remove bogus const from decipher_sync_action() return type dm mpath: fix attached_handler_name leak and dangling hw_handler_name pointer dm thin metadata: fix __udivdi3 undefined on 32-bit

dm cache: fix resize crash if user doesn't reload cache table

2018-10-04T19:20:52Z

A reload of the cache's DM table is needed during resize because otherwise a crash will occur when attempting to access smq policy entries associated with the portion of the cache that was recently extended. The reason is cache-size based data structures in the policy will not be resized, the only way to safely extend the cache is to allow for a proper cache policy initialization that occurs when the cache table is loaded. For example the smq policy's space_init(), init_allocator(), calc_hotspot_params() must be sized based on the extended cache size. The fix for this is to disallow cache resizes of this pattern: 1) suspend "cache" target's device 2) resize the fast device used for the cache 3) resume "cache" target's device Instead, the last step must be a full reload of the cache's DM table. Fixes: 66a636356 ("dm cache: add stochastic-multi-queue (smq) policy") Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer

dm cache metadata: ignore hints array being too small during resize

2018-10-04T19:20:51Z

Commit fd2fa9541 ("dm cache metadata: save in-core policy_hint_size to on-disk superblock") enabled previously written policy hints to be used after a cache is reactivated. But in doing so the cache metadata's hint array was left exposed to out of bounds access because on resize the metadata's on-disk hint array wasn't ever extended. Fix this by ignoring that there are no on-disk hints associated with the newly added cache blocks. An expanded on-disk hint array is later rewritten upon the next clean shutdown of the cache. Fixes: fd2fa9541 ("dm cache metadata: save in-core policy_hint_size to on-disk superblock") Cc: stable@vger.kernel.org Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer

Merge tag 'for-linus-20180929' of git://git.kernel.dk/linux-block

2018-09-29T21:52:14Z

Jens writes: "Block fixes for 4.19-rc6 A set of fixes that should go into this release. This pull request contains: - A fix (hopefully) for the persistent grants for xen-blkfront. A previous fix from this series wasn't complete, hence reverted, and this one should hopefully be it. (Boris Ostrovsky) - Fix for an elevator drain warning with SMR devices, which is triggered when you switch schedulers (Damien) - bcache deadlock fix (Guoju Fang) - Fix for the block unplug tracepoint, which has had the timer/explicit flag reverted since 4.11 (Ilya) - Fix a regression in this series where the blk-mq timeout hook is invoked with the RCU read lock held, hence preventing it from blocking (Keith) - NVMe pull from Christoph, with a single multipath fix (Susobhan Dey)" * tag 'for-linus-20180929' of git://git.kernel.dk/linux-block: xen/blkfront: correct purging of persistent grants Revert "xen/blkfront: When purging persistent grants, keep them in the buffer" blk-mq: I/O and timer unplugs are inverted in blktrace bcache: add separate workqueue for journal_write to avoid deadlock xen/blkfront: When purging persistent grants, keep them in the buffer block: fix deadline elevator drain for zoned block devices blk-mq: Allow blocking queue tag iter callbacks nvme: properly propagate errors in nvme_mpath_init