On 6/16/22 19:09, Pankaj Raghav wrote:
> On 2022-06-15 22:28, Bart Van Assche wrote:
> isk_name, zone->len);
>>> + if (zone->len == 0) {
>>> + pr_warn("%s: Invalid zone size", disk->disk_name);
>>> + return -ENODEV;
>>> + }
>>> +
>>> + /*
>>> + * Don't allow zoned device with non power_of_2 zone size with
>>> + * zone capacity less than zone size.
>>> + */
>>
>
>> Please change "power_of_2" into "power-of-2".
>>
> Ok.
>>> + if (!is_power_of_2(zone->len) && zone->capacity < zone->len) {
>>> + pr_warn("%s: Invalid zone capacity for non power of 2
>>> zone size",
>>> + disk->disk_name);
>>> return -ENODEV;
>>> }
>>
>> The above check seems wrong to me. I don't see why devices that report a
>> capacity that is less than the zone size should be rejected.
>>
> This was brought up by Damien during previous reviews. The argument was
> that the reason to allow non power-of-2 zoned device is to remove the
> gaps between zone size and zone capacity. Allowing a npo2 zone size with
> a different capacity, even though it is technically possible, it does
> not make any practical sense. That is why this check was introduced.
> Does that answer your question?
Add a comment explaining this restriction, clearly mentioning that it is a
Linux restrictions and not mandated by the specifications.
>>> + /*
>>> + * Division is used to calculate nr_zones for both power_of_2
>>> + * and non power_of_2 zone sizes as it is not in the hot path.
>>> + */
>>
>> Shouldn't the above comment be moved to the patch description? I'm not
>> sure whether having such a comment in the source code is valuable.
>>
> Yeah, I will remove it. Maybe it is very obvious at this point.
>>> +static inline sector_t blk_queue_offset_from_zone_start(struct
>>> request_queue *q,
>>> + sector_t sec)
>>> +{
>>> + sector_t zone_sectors = blk_queue_zone_sectors(q);
>>> + u64 remainder = 0;
>>> +
>>> + if (!blk_queue_is_zoned(q))
>>> + return false;
>>
>> "return false" should only occur in functions returning a boolean. This
>> function returns type sector_t.
>>
> Good catch. It was a copy paste mistake. Fixed it.
>> Thanks,
>>
>> Bart.
>
> --
> dm-devel mailing list
> dm-devel@xxxxxxxxxx
> https://listman.redhat.com/mailman/listinfo/dm-devel
--
Damien Le Moal
Western Digital Research
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
