linux-toradex.git/drivers/md/dm-target.c, branch v6.13-rc7

dm: always manage discard support in terms of max_hw_discard_sectors

2024-05-20T19:51:19+00:00

Commit 4f563a64732d ("block: add a max_user_discard_sectors queue
limit") changed block core to set max_discard_sectors to:
 min(lim->max_hw_discard_sectors, lim->max_user_discard_sectors)

Since commit 1c0e720228ad ("dm: use queue_limits_set") it was reported
dm-thinp was failing in a few fstests (generic/347 and generic/405)
with the first WARN_ON_ONCE in dm_cell_key_has_valid_range() being
reported, e.g.:
WARNING: CPU: 1 PID: 30 at drivers/md/dm-bio-prison-v1.c:128 dm_cell_key_has_valid_range+0x3d/0x50

blk_set_stacking_limits() sets max_user_discard_sectors to UINT_MAX,
so given how block core now sets max_discard_sectors (detailed above)
it follows that blk_stack_limits() stacks up the underlying device's
max_hw_discard_sectors and max_discard_sectors is set to match it. If
max_hw_discard_sectors exceeds dm's BIO_PRISON_MAX_RANGE, then
dm_cell_key_has_valid_range() will trigger the warning with:
WARN_ON_ONCE(key->block_end - key->block_begin > BIO_PRISON_MAX_RANGE)

Aside from this warning, the discard will fail.  Fix this and other DM
issues by governing discard support in terms of max_hw_discard_sectors
instead of max_discard_sectors.

Reported-by: Theodore Ts'o 
Fixes: 1c0e720228ad ("dm: use queue_limits_set")
Signed-off-by: Mike Snitzer

dm error: Add support for zoned block devices

2023-10-31T15:06:21+00:00

dm-error is used in several test cases in the xfstests test suite to
check the handling of IO errors in file systems. However, with several
file systems getting native support for zoned block devices (e.g.
btrfs and f2fs), dm-error's lack of zoned block device support creates
problems as the file system attempts executing zone commands (e.g. a
zone append operation) against a dm-error non-zoned block device,
which causes various issues in the block layer (e.g. WARN_ON
triggers).

This commit adds supports for zoned block devices to dm-error, allowing
a DM device table containing an error target to be exposed as a zoned
block device (if all targets have a compatible zoned model support and
mapping). This is done as follows:
1) Allow passing 2 arguments to an error target, similar to dm-linear:
   a backing device and a start sector. These arguments are optional and
   dm-error retains its characteristics if the arguments are not
   specified.
2) Implement the iterate_devices method so that dm-core can normally
   check the zone support and restrictions (e.g. zone alignment of the
   targets). When the backing device arguments are not specified, the
   iterate_devices method never calls the fn() argument.
When no backing device is specified, as before, we assume that the DM
device is not zoned. When the backing device arguments are specified,
the zoned model of the DM device will depend on the backing device
type:
 - If the backing device is zoned and its model and mapping is
   compatible with other targets of the device, the resulting device
   will be zoned, with the dm-error mapped portion always returning
   errors (similar to the default non-zoned case).
 - If the backing device is not zoned, then the DM device will not be
   either.

This zone support for dm-error requires the definition of a functional
report_zones operation so that dm_revalidate_zones() can operate
correctly and resources for emulating zone append operations
initialized. This is necessary for cases where dm-error is used to
partially map a device and have an overall correct handling of zone
append. This means that dm-error does not fail report zones operations.

Two changes that are not obvious are included to avoid issues:
1) dm_table_supports_zoned_model() is changed to directly check if
   the backing device of a wildcard target (= dm-error target) is
   zoned. Otherwise, we wouldn't be able to catch the invalid setup of
   dm-error without a backing device (non zoned case) being combined
   with zoned targets.
2) dm_table_supports_dax() is modified to return false if the wildcard
   target is found. Otherwise, when dm-error is set without a backing
   device, we end up with a NULL pointer dereference in
   set_dax_synchronous (dax_dev is NULL). This is consistent with the
   current behavior because dm_table_supports_dax() always returned
   false for targets that do not define the iterate_devices method.

Signed-off-by: Damien Le Moal 
Tested-by: Christoph Hellwig 
Signed-off-by: Mike Snitzer

dm: push error reporting down to dm_register_target()

2023-04-11T16:01:01+00:00

Simplifies each DM target's init method by making dm_register_target()
responsible for its error reporting (on behalf of targets).

Signed-off-by: Yangtao Li 
Signed-off-by: Mike Snitzer

dm error: add discard support

2023-04-04T17:30:17+00:00

Add io_err_io_hints() and set discard limits so that the zero target
advertises support for discards.

The error target will return -EIO for discards.

This is useful when the user combines dm-error with other
discard-supporting targets in the same table; without dm-error
support, discards would be disabled for the whole combined device.

Signed-off-by: Mikulas Patocka 
Tested-by: Milan Broz 
Signed-off-by: Mike Snitzer

dm: adjust EXPORT_SYMBOL() to follow functions immediately

2023-02-14T19:23:07+00:00

Signed-off-by: Heinz Mauelshagen 
Signed-off-by: Mike Snitzer

dm: add missing SPDX-License-Indentifiers

2023-02-14T19:23:06+00:00

'GPL-2.0-only' is used instead of 'GPL-2.0' because SPDX has
deprecated its use.

Suggested-by: John Wiele 
Signed-off-by: Heinz Mauelshagen 
Signed-off-by: Mike Snitzer

dax: introduce DAX_RECOVERY_WRITE dax access mode

2022-05-16T20:35:56+00:00

Up till now, dax_direct_access() is used implicitly for normal
access, but for the purpose of recovery write, dax range with
poison is requested.  To make the interface clear, introduce
	enum dax_access_mode {
		DAX_ACCESS,
		DAX_RECOVERY_WRITE,
	}
where DAX_ACCESS is used for normal dax access, and
DAX_RECOVERY_WRITE is used for dax recovery write.

Suggested-by: Dan Williams 
Signed-off-by: Jane Chu 
Reviewed-by: Christoph Hellwig 
Cc: Mike Snitzer 
Reviewed-by: Vivek Goyal 
Link: https://lore.kernel.org/r/165247982851.52965.11024212198889762949.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams

dm mpath: fix missing call of path selector type->end_io

2019-04-25T19:38:52+00:00

After commit 396eaf21ee17 ("blk-mq: improve DM's blk-mq IO merging via
blk_insert_cloned_request feedback"), map_request() will requeue the tio
when issued clone request return BLK_STS_RESOURCE or BLK_STS_DEV_RESOURCE.

Thus, if device driver status is error, a tio may be requeued multiple
times until the return value is not DM_MAPIO_REQUEUE.  That means
type->start_io may be called multiple times, while type->end_io is only
called when IO complete.

In fact, even without commit 396eaf21ee17, setup_clone() failure can
also cause tio requeue and associated missed call to type->end_io.

The service-time path selector selects path based on in_flight_size,
which is increased by st_start_io() and decreased by st_end_io().
Missed calls to st_end_io() can lead to in_flight_size count error and
will cause the selector to make the wrong choice.  In addition,
queue-length path selector will also be affected.

To fix the problem, call type->end_io in ->release_clone_rq before tio
requeue.  map_info is passed to ->release_clone_rq() for map_request()
error path that result in requeue.

Fixes: 396eaf21ee17 ("blk-mq: improve DM's blk-mq IO merging via blk_insert_cloned_request feedback")
Cc: stable@vger.kernl.org
Signed-off-by: Yufen Yu 
Signed-off-by: Mike Snitzer

dm: remove unused macro DM_MOD_NAME_SIZE

2018-04-03T19:04:15+00:00

Signed-off-by: Wang Sheng-Hui 
Signed-off-by: Mike Snitzer

dm: don't return errnos from ->map

2017-06-09T15:27:32+00:00

Instead use the special DM_MAPIO_KILL return value to return -EIO just
like we do for the request based path.  Note that dm-log-writes returned
-ENOMEM in a few places, which now becomes -EIO instead.  No consumer
treats -ENOMEM special so this shouldn't be an issue (and it should
use a mempool to start with to make guaranteed progress).

Signed-off-by: Christoph Hellwig 
Signed-off-by: Mike Snitzer 
Signed-off-by: Jens Axboe