From: Damien Le Moal <dlemoal@kernel.org>
To: Tao Cui <cui.tao@linux.dev>, Mark Brown <broonie@kernel.org>
Cc: linux-next@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, cuitao@kylinos.cn
Subject: Re: next-20260917 and next-20260918: merge of the block tree breaks all zoned devices
Date: Mon, 21 Sep 2026 11:31:11 +0900 [thread overview]
Message-ID: <0ed54aa9-2cc6-4051-abe7-8144f39f6bed@kernel.org> (raw)
In-Reply-To: <7141040b-5a15-471f-9bbf-9a18bed864e7@linux.dev>
[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]
On 9/21/26 09:49, Tao Cui wrote:
> Hi Mark, Damien,
>
> 在 2026/9/21 06:37, Damien Le Moal 写道:
>> On 9/21/26 00:18, Mark Brown wrote:
>>> I did say when I did that merge that I had no confidence in it but
>>> nobody responded. Can you please send me a commit on top of current
>>> -next which fixes up the resolution appropriately? I can drop extra
>>> fixups in relatively easily, it's probably safer to take something that
>>> you have tested.
>>
>> Mark,
>>
>> My apologies for not replying, but I was traveling. I had looked at your
>> resolution but only quickly and I did not notice the incorrect comparison
>> causing the issue.
>>
>> I am attaching a diff that cleans up the conflict resolution.
>>
>
> I tested Damien's patch on top of next-20260918.
>
> It restores the zoned null_blk here: nullb0 is created again, reports
> host-managed, and the queue chunk size is back to 131072 sectors
> (CONFIG_BLK_DEV_NULL_BLK=y, "null_blk.zoned=1 null_blk.gb=1
> null_blk.zone_size=64" on the kernel command line). So this looks
> good to me.
>
> Tested-by: Tao Cui <cuitao@kylinos.cn>
>
> One question for Damien while looking through the merged code: both
> parents had the power-of-two check for zone_sectors, but that check
> also disappears in the merged result. Was that removal intentional,
> or should it be restored as well?
Mark, Attaching a v2 diff for corrected the conflict resolution. This is on top
of the current linux-next.
Thanks.
--
Damien Le Moal
Western Digital Research
[-- Attachment #2: v2-blk-zoned.diff --]
[-- Type: text/x-patch, Size: 1907 bytes --]
diff --git a/block/blk-zoned.c b/block/blk-zoned.c
index bae48f0d3464..19268afb8752 100644
--- a/block/blk-zoned.c
+++ b/block/blk-zoned.c
@@ -2031,11 +2031,16 @@ void disk_init_zone_resources(struct gendisk *disk)
static unsigned int disk_get_nr_zones(struct gendisk *disk, sector_t capacity)
{
struct queue_limits *lim = &disk->queue->limits;
+ unsigned long long nr_zones;
if (!capacity || !lim->chunk_sectors)
return 0;
- return DIV_ROUND_UP_ULL(capacity, lim->chunk_sectors);
+ nr_zones = DIV_ROUND_UP_ULL(capacity, lim->chunk_sectors);
+ if (nr_zones > UINT_MAX)
+ return 0;
+
+ return nr_zones;
}
/*
@@ -2197,8 +2202,8 @@ static int disk_init_revalidate_args(struct gendisk *disk,
{
args->disk = disk;
args->nr_zones = disk_get_nr_zones(disk, args->capacity);
- if (args->nr_zones > UINT_MAX)
- return -EINVAL;
+ if (!args->nr_zones)
+ return -ENODEV;
/* Cached zone conditions: 1 byte per zone */
args->zones_state = kzalloc(args->nr_zones, GFP_NOIO);
@@ -2322,15 +2327,22 @@ static void disk_drop_zone_wplug(struct blk_zone_wplug *zwplug, void *data)
static int disk_revalidate_capacity(struct gendisk *disk,
struct blk_revalidate_zone_args *args)
{
+ struct queue_limits *lim = &disk->queue->limits;
+ sector_t zone_sectors = lim->chunk_sectors;
unsigned int nr_zones;
int ret = -ENODEV;
+ /* Checks that the device driver indicated a valid zone size. */
+ if (!zone_sectors || !is_power_of_2(zone_sectors)) {
+ pr_warn("%s: Invalid non power of two zone size (%llu)\n",
+ disk->disk_name, zone_sectors);
+ goto drop_all_zwplugs;
+ }
+
args->capacity = get_capacity(disk);
nr_zones = disk_get_nr_zones(disk, args->capacity);
if (!args->capacity || !nr_zones)
goto drop_all_zwplugs;
- if (args->capacity >= args->nr_zones)
- goto drop_all_zwplugs;
/*
* Check if the capacity has changed. If it did, assume that the device
next prev parent reply other threads:[~2026-09-21 2:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-20 12:58 next-20260917 and next-20260918: merge of the block tree breaks all zoned devices Tao Cui
2026-09-20 13:12 ` Stephen Rothwell
2026-09-20 15:18 ` Mark Brown
2026-09-20 22:37 ` Damien Le Moal
2026-09-21 0:49 ` Tao Cui
2026-09-21 2:07 ` Damien Le Moal
2026-09-21 2:31 ` Damien Le Moal [this message]
2026-09-21 10:29 ` Mark Brown
2026-09-21 8:24 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0ed54aa9-2cc6-4051-abe7-8144f39f6bed@kernel.org \
--to=dlemoal@kernel.org \
--cc=axboe@kernel.dk \
--cc=broonie@kernel.org \
--cc=cui.tao@linux.dev \
--cc=cuitao@kylinos.cn \
--cc=linux-block@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.