Re: [PATCH 2/2] block: fix the length of a smaller last zone in blkdev_get_zone_info()

[Damien Le Moal <dlemoal@kernel.org>]

On 2026/10/12 14:41, shashank Jain wrote:
> On Mon, Oct 12, 2026, Damien Le Moal wrote:
>> How do you plan to issue a BLK_ZONE_REP_CACHED report? "blkzone report"
>> does not have that yet. I am planning to send a patch for it.
> 
> Good point. Two options, and I am happy to follow your preference:
> 
> - Use "blkzone report" with the cached flag once your util-linux patch
>   lands - that matches the existing zbd tests and avoids a bundled tool.
>   I would hold the blktests submission until it is available.

We should leave "blkzone report" to get the device report as before, to avoid
breaking anything for user with the "active" condition being returned.
I was thinking on adding a "--cached" option to control the use of
BLK_ZONE_REP_CACHED.

If you want to take on such patch, go ahead. CC me on it and I will review. The
patches I need to send to add depop support will take some more time.

> - Or carry a small C helper in the blktests src/ directory that issues
>   BLKREPORTZONEV2 with BLK_ZONE_REP_CACHED directly, so the test is
>   self-contained and does not depend on the util-linux version.
> 
> I lean towards the first, to match the zbd conventions and your blkzone
> work; tell me which you prefer and I will align the test with it.
> 
> Thanks,
> Shashank
> 
> On Mon, Oct 12, 2026 at 6:07 PM Damien Le Moal <dlemoal@kernel.org> wrote:
>>
>> On 2026/10/12 14:29, shashank Jain wrote:
>>> On Mon, Oct 12, 2026, Christoph Hellwig wrote:
>>>> Can you add this to blktests as a reproducer?
>>>
>>> Will do. I'll send a blktests test under tests/zbd/ that sets up a zoned
>>> null_blk device with a smaller last zone and checks that BLKREPORTZONEV2
>>> without BLK_ZONE_REP_CACHED matches BLKREPORTZONE, and that the cached
>>> report's last-zone length does not extend past the device. I'll post it
>>> to the blktests project separately and reference this series.
>>
>> How do you plan to issue a BLK_ZONE_REP_CACHED report? "blkzone report" does not
>> have that yet. I am planning to send a patch for it.
>>
>>>
>>> Thanks,
>>> Shashank
>>>
>>> On Mon, Oct 12, 2026 at 5:51 PM Christoph Hellwig <hch@lst.de> wrote:
>>>>
>>>> On Sun, Oct 11, 2026 at 10:49:06AM +0530, Shashank Mohan Jain wrote:
>>>>> blkdev_get_zone_info() sets the length of every zone to the zone size
>>>>> of the device. The last zone of a zoned block device may be smaller
>>>>> than the others: blk_revalidate_zone_cb() accepts that and remembers
>>>>> the capacity of that zone in disk->last_zone_capacity. For such a zone
>>>>> the length reported from the cached information is too large, and
>>>>> start + len is beyond the end of the device. A conventional last zone
>>>>> is also given the capacity of a full zone.
>>>>>
>>>>> Example with a zoned null_blk device of 10 MiB (20480 sectors) with
>>>>> 4 MiB zones, last zone:
>>>>>
>>>>>   BLKREPORTZONE:       start 16384 len 4096 capacity 4096
>>>>>   BLKREPORTZONEV2 with
>>>>>   BLK_ZONE_REP_CACHED: start 16384 len 8192 capacity 4096
>>>>
>>>> Can you add this to blktests as a reproducer?
>>>>
>>>> The patch looks good:
>>>>
>>>>
>>>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>>
>>
>> --
>> Damien Le Moal
>> Western Digital Research


-- 
Damien Le Moal
Western Digital Research