On Tue, May 21, 2024 at 10:51 PM Mike Snitzer <snitzer@xxxxxxxxxx> wrote:
>
> Otherwise, blk_validate_limits() will throw-away the max_sectors that
> was stacked from underlying device(s). In doing so it can set a
> max_sectors limit that violates underlying device limits.
>
> This caused dm-multipath IO failures like the following because the
> underlying devices' max_sectors were stacked up to be 1024, yet
> blk_validate_limits() defaulted max_sectors to BLK_DEF_MAX_SECTORS_CAP
> (2560):
>
> [ 1214.673233] blk_insert_cloned_request: over max size limit. (2048 > 1024)
> [ 1214.673267] device-mapper: multipath: 254:3: Failing path 8:32.
> [ 1214.675196] blk_insert_cloned_request: over max size limit. (2048 > 1024)
> [ 1214.675224] device-mapper: multipath: 254:3: Failing path 8:16.
> [ 1214.675309] blk_insert_cloned_request: over max size limit. (2048 > 1024)
> [ 1214.675338] device-mapper: multipath: 254:3: Failing path 8:48.
> [ 1214.675413] blk_insert_cloned_request: over max size limit. (2048 > 1024)
> [ 1214.675441] device-mapper: multipath: 254:3: Failing path 8:64.
>
> The initial bug report included:
>
> [ 13.822701] blk_insert_cloned_request: over max size limit. (248 > 128)
> [ 13.829351] device-mapper: multipath: 253:3: Failing path 8:32.
> [ 13.835307] blk_insert_cloned_request: over max size limit. (248 > 128)
> [ 13.841928] device-mapper: multipath: 253:3: Failing path 65:16.
> [ 13.844532] blk_insert_cloned_request: over max size limit. (248 > 128)
> [ 13.854363] blk_insert_cloned_request: over max size limit. (248 > 128)
> [ 13.854580] device-mapper: multipath: 253:4: Failing path 8:48.
> [ 13.861166] device-mapper: multipath: 253:3: Failing path 8:192.
>
> Reported-by: Marco Patalano <mpatalan@xxxxxxxxxx>
> Reported-by: Ewan Milne <emilne@xxxxxxxxxx>
> Fixes: 1c0e720228ad ("dm: use queue_limits_set")
> Signed-off-by: Mike Snitzer <snitzer@xxxxxxxxxx>
> ---
> drivers/md/dm-table.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
> index 88114719fe18..6463b4afeaa4 100644
> --- a/drivers/md/dm-table.c
> +++ b/drivers/md/dm-table.c
> @@ -1961,6 +1961,7 @@ int dm_table_set_restrictions(struct dm_table *t, struct request_queue *q,
> struct queue_limits *limits)
> {
> bool wc = false, fua = false;
> + unsigned int max_hw_sectors;
> int r;
>
> if (dm_table_supports_nowait(t))
> @@ -1981,9 +1982,16 @@ int dm_table_set_restrictions(struct dm_table *t, struct request_queue *q,
> if (!dm_table_supports_secure_erase(t))
> limits->max_secure_erase_sectors = 0;
>
> + /* Don't allow queue_limits_set() to throw-away stacked max_sectors */
> + max_hw_sectors = limits->max_hw_sectors;
> + limits->max_hw_sectors = limits->max_sectors;
> r = queue_limits_set(q, limits);
> if (r)
> return r;
> + /* Restore stacked max_hw_sectors */
> + mutex_lock(&q->limits_lock);
> + limits->max_hw_sectors = max_hw_sectors;
> + mutex_unlock(&q->limits_lock);
>
> if (dm_table_supports_flush(t, (1UL << QUEUE_FLAG_WC))) {
> wc = true;
> --
> 2.43.0
>
This fixed the FC DM-MP failures, so:
Tested-by: Marco Patalano <mpatalan@xxxxxxxxxx>
Revewied-by: Ewan D. Milne <emilne@xxxxxxxxxx>
