next-20260917 and next-20260918: merge of the block tree breaks all zoned devices

[Tao Cui <cui.tao@linux.dev>]

Hi Stephen,

I ran into this while testing a blk-iocost series of mine (charging
zone appends as writes) against a zoned null_blk: the device simply
does not show up, whether configured through module parameters or
configfs.  null_blk prints "using native zone append" and then
add_disk() fails silently with -ENODEV.

My series only touches blk-iocost.c, and the failure reproduces on
plain linux-next, so it is not mine.  Bisecting over the tags (qemu,
"null_blk.zoned=1 null_blk.gb=1 null_blk.zone_size=64" on the command
line) narrows it down to one day:

  next-20260916: nullb0 created, /sys/block/nullb0/queue/zoned = host-managed
  next-20260917: no device, add_disk() fails
  next-20260918: same failure

The only blk-zoned.c changes between next-20260916 and next-20260917
come in through the merge of the block tree, and next-20260918 repeats
the same resolution in the same place:

  66c8b6b56c09 ("Merge branch 'for-next' of .../axboe/linux.git", 2026-09-17)
  a9ce2250a714 ("Merge branch 'for-next' of .../axboe/linux.git", 2026-09-18)

As far as I can tell the resolved disk_revalidate_capacity() matches
neither parent: it gains a

  if (args->capacity >= args->nr_zones)

check that compares a sector count against a zone count, with
args->nr_zones still 0 on the first call, so it always trips and
blk_revalidate_disk_zones() always returns -ENODEV.  The zone_sectors
power-of-two check that both parents have is gone as well.  This hits
every zoned device, not just null_blk.

Taking the axboe side of the function makes nullb0 come back on
next-20260918 here (host-managed, chunk_sectors 131072), so it looks
like the merge should just have taken that side.

Same conflict, same bad outcome twice in a row now, so tomorrow's
merge may hit it again unless the block tree has moved on in this
area.

Regards,
Tao