| Message ID | 20240524062119.143788-1-hare@kernel.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | block: blk_set_stacking_limits() doesn't validate | expand |
On Fri, May 24, 2024 at 08:21:19AM +0200, Hannes Reinecke wrote: > blk_validate_zoned_limits() checks whether any of the zoned limits > are set for non-zoned limits. As blk_set_stacking_limits() sets > max_zone_append_sectors() it'll fail to validate. Except that you now broke it for zone devices. Normally if we are not building a stacked zoned device there should at least be one underlying device that has a zero max_zone_append_limit, thus lowering the stacked device limit to 0. I guess you have a scenario where that is not the case, so please explain it so that we can fix it.
On 5/24/24 09:39, Christoph Hellwig wrote: > On Fri, May 24, 2024 at 08:21:19AM +0200, Hannes Reinecke wrote: >> blk_validate_zoned_limits() checks whether any of the zoned limits >> are set for non-zoned limits. As blk_set_stacking_limits() sets >> max_zone_append_sectors() it'll fail to validate. > > Except that you now broke it for zone devices. Normally if we are > not building a stacked zoned device there should at least be one > underlying device that has a zero max_zone_append_limit, thus lowering > the stacked device limit to 0. I guess you have a scenario where that > is not the case, so please explain it so that we can fix it. > I just found it weird that a simple 'memset' for the initial device configuration and then calling blk_set_stacking_limits() will lead to a failure in blk_validate_limits() ... But I'll relent; this had been coming up during large block testing with NVMe, but was only tangentially related. So I'll retract it. Cheers, Hannes
On Fri, May 24, 2024 at 11:56:17AM +0200, Hannes Reinecke wrote: > I just found it weird that a simple 'memset' for the initial device > configuration and then calling blk_set_stacking_limits() will lead to a > failure in blk_validate_limits() ... You don't need a memset before calling blk_set_stacking_limits as blk_set_stacking_limits already does the memset for you. But as implied by the name and documented in the kerneldoc comment, blk_set_stacking_limits is indeed intended to prepare for stacking in other limits and is not supposed to be directly applied.
diff --git a/block/blk-settings.c b/block/blk-settings.c index d2731843f2fc..524cf597b2e9 100644 --- a/block/blk-settings.c +++ b/block/blk-settings.c @@ -50,7 +50,6 @@ void blk_set_stacking_limits(struct queue_limits *lim) lim->max_sectors = UINT_MAX; lim->max_dev_sectors = UINT_MAX; lim->max_write_zeroes_sectors = UINT_MAX; - lim->max_zone_append_sectors = UINT_MAX; lim->max_user_discard_sectors = UINT_MAX; } EXPORT_SYMBOL(blk_set_stacking_limits);
blk_validate_zoned_limits() checks whether any of the zoned limits are set for non-zoned limits. As blk_set_stacking_limits() sets max_zone_append_sectors() it'll fail to validate. Signed-off-by: Hannes Reinecke <hare@kernel.org> --- block/blk-settings.c | 1 - 1 file changed, 1 deletion(-)