Linux block layer
 help / color / mirror / Atom feed
* [PATCH] block: stack zoned resource limits
@ 2026-05-20  9:12 Yao Sang
  2026-05-21  3:54 ` Shin'ichiro Kawasaki
  2026-05-31  9:45 ` kernel test robot
  0 siblings, 2 replies; 3+ messages in thread
From: Yao Sang @ 2026-05-20  9:12 UTC (permalink / raw)
  To: linux-block; +Cc: Jens Axboe, Yao Sang

This was found while debugging a zoned NVMe multipath setup, where the
namespace head reported 0/0 for max_open_zones and max_active_zones
while the live path still reported finite limits.

blk_stack_limits() already combines several zoned queue limits, but it
leaves max_open_zones and max_active_zones unchanged. Since 0 means "no
limit" for both values, stacked zoned devices can preserve bogus 0/0
limits even when the underlying queue advertises finite values.

Stack max_open_zones and max_active_zones with min_not_zero(), and
clear them when the resulting queue is not zoned.

Signed-off-by: Yao Sang <sangyao@kylinos.cn>
---
 block/blk-settings.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index 78c83817b9d3..88b6c3703101 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -814,6 +814,10 @@ int blk_stack_limits(struct queue_limits *t, struct queue_limits *b,
 
 	t->max_hw_zone_append_sectors = min(t->max_hw_zone_append_sectors,
 					b->max_hw_zone_append_sectors);
+	t->max_open_zones = min_not_zero(t->max_open_zones,
+				       b->max_open_zones);
+	t->max_active_zones = min_not_zero(t->max_active_zones,
+					 b->max_active_zones);
 
 	t->seg_boundary_mask = min_not_zero(t->seg_boundary_mask,
 					    b->seg_boundary_mask);
@@ -921,6 +925,8 @@ int blk_stack_limits(struct queue_limits *t, struct queue_limits *b,
 	t->zone_write_granularity = max(t->zone_write_granularity,
 					b->zone_write_granularity);
 	if (!(t->features & BLK_FEAT_ZONED)) {
+		t->max_open_zones = 0;
+		t->max_active_zones = 0;
 		t->zone_write_granularity = 0;
 		t->max_zone_append_sectors = 0;
 	}
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] block: stack zoned resource limits
  2026-05-20  9:12 [PATCH] block: stack zoned resource limits Yao Sang
@ 2026-05-21  3:54 ` Shin'ichiro Kawasaki
  2026-05-31  9:45 ` kernel test robot
  1 sibling, 0 replies; 3+ messages in thread
From: Shin'ichiro Kawasaki @ 2026-05-21  3:54 UTC (permalink / raw)
  To: Yao Sang; +Cc: linux-block, Jens Axboe

On May 20, 2026 / 17:12, Yao Sang wrote:
> This was found while debugging a zoned NVMe multipath setup, where the
> namespace head reported 0/0 for max_open_zones and max_active_zones
> while the live path still reported finite limits.
> 
> blk_stack_limits() already combines several zoned queue limits, but it
> leaves max_open_zones and max_active_zones unchanged. Since 0 means "no
> limit" for both values, stacked zoned devices can preserve bogus 0/0
> limits even when the underlying queue advertises finite values.
> 
> Stack max_open_zones and max_active_zones with min_not_zero(), and
> clear them when the resulting queue is not zoned.
> 
> Signed-off-by: Yao Sang <sangyao@kylinos.cn>

Hello Yao,

Blktest CI system found that this patch makes the test case zbd/011 fail [1].
The header comment of the test case explains how max_open_zones and
max_active_zones should be handled [2]. You may also want to check the
corresponding kernel side commit 73a74af0c72b ("dm: Improve zone resource
limits handling").

[1]

$ sudo ./check zbd/011
Memory leak detected before test run start. See '/home/shin/Blktests/blktests/results/start.kmemleak'.
zbd/011 (DM zone resource limits stacking)                   [failed]
    runtime  9.791s  ...  10.764s
    --- tests/zbd/011.out       2025-04-22 13:13:27.805873155 +0900
    +++ /home/shin/Blktests/blktests/results/nodev/zbd/011.out.bad      2026-05-21 12:49:44.398000000 +0900
    @@ -1,2 +1,13 @@
     Running zbd/011
    +Invalid max active zones limit: 64 should be 0
    +Test 9 failed: Map 32 CNV zones of the 1st nullb and all SWR zones of the 2nd nullb
    +Invalid max active zones limit: 64 should be 0
    +Test 11 failed: Map 32 SWR zones of the 1st nullb and all SWR zones of the 2nd nullb
    +Invalid max open zones limit: 48 should be 64
    +Test 12 failed: Map 128 SWR zones of the 1st nullb and 16 SWR zones of the 2nd nullb
    ...
    (Run 'diff -u tests/zbd/011.out /home/shin/Blktests/blktests/results/nodev/zbd/011.out.bad' to see the entire diff)

[2] https://github.com/linux-blktests/blktests/blob/master/tests/zbd/011

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] block: stack zoned resource limits
  2026-05-20  9:12 [PATCH] block: stack zoned resource limits Yao Sang
  2026-05-21  3:54 ` Shin'ichiro Kawasaki
@ 2026-05-31  9:45 ` kernel test robot
  1 sibling, 0 replies; 3+ messages in thread
From: kernel test robot @ 2026-05-31  9:45 UTC (permalink / raw)
  To: Yao Sang; +Cc: oe-lkp, lkp, linux-block, Jens Axboe, Yao Sang, oliver.sang



Hello,

kernel test robot noticed "blktests.zbd/011.fail" on:

commit: c17db973b5faf59694eda2e4ea164b29b69c8973 ("[PATCH] block: stack zoned resource limits")
url: https://github.com/intel-lab-lkp/linux/commits/Yao-Sang/block-stack-zoned-resource-limits/20260520-174028
base: https://git.kernel.org/cgit/linux/kernel/git/axboe/linux.git for-next
patch link: https://lore.kernel.org/all/20260520091237.392802-1-sangyao@kylinos.cn/
patch subject: [PATCH] block: stack zoned resource limits

in testcase: blktests
version: blktests-x86_64-9131687-1_20260529
with following parameters:

	test: zbd-011


config: x86_64-rhel-9.4-func
compiler: gcc-14
test machine: 4 threads Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (Skylake) with 32G memory

(please refer to attached dmesg/kmsg for entire log/backtrace)



If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202605311745.77820afc-lkp@intel.com


2026-05-29 09:25:41 cd /lkp/benchmarks/blktests
Defaulting to policy_version 2 because kernel supports it.
Customizing passphrase hashing difficulty for this system...
Created global config file at "/etc/fscrypt.conf".
Allow users other than root to create fscrypt metadata on the root filesystem?
(See https://github.com/google/fscrypt#setting-up-fscrypt-on-a-filesystem) [y/N] Metadata directories created at "/.fscrypt", writable by root only.
2026-05-29 09:25:47 echo zbd/011
2026-05-29 09:25:47 ./check zbd/011
zbd/011 (DM zone resource limits stacking)                  
zbd/011 (DM zone resource limits stacking)                   [failed]
    runtime    ...  6.852s
    --- tests/zbd/011.out	2026-05-29 06:56:18.000000000 +0000
    +++ /lkp/benchmarks/blktests/results/nodev/zbd/011.out.bad	2026-05-29 09:25:54.319411071 +0000
    @@ -1,2 +1,13 @@
     Running zbd/011
    +Invalid max active zones limit: 64 should be 0
    +Test 9 failed: Map 32 CNV zones of the 1st nullb and all SWR zones of the 2nd nullb
    +Invalid max active zones limit: 64 should be 0
    +Test 11 failed: Map 32 SWR zones of the 1st nullb and all SWR zones of the 2nd nullb
    +Invalid max open zones limit: 48 should be 64
    +Test 12 failed: Map 128 SWR zones of the 1st nullb and 16 SWR zones of the 2nd nullb
    ...
    (Run 'diff -u tests/zbd/011.out /lkp/benchmarks/blktests/results/nodev/zbd/011.out.bad' to see the entire diff)



The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260531/202605311745.77820afc-lkp@intel.com



-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-05-31  9:45 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-20  9:12 [PATCH] block: stack zoned resource limits Yao Sang
2026-05-21  3:54 ` Shin'ichiro Kawasaki
2026-05-31  9:45 ` kernel test robot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox