linux-kernel - Re: [PATCH v2] null_blk: add support for max open/active zone limit for zoned devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 28 Aug 2020 10:29:17 +0000
From:   Damien Le Moal <Damien.LeMoal@....com>
To:     Niklas Cassel <Niklas.Cassel@....com>
CC:     Jens Axboe <axboe@...nel.dk>,
        Johannes Thumshirn <Johannes.Thumshirn@....com>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] null_blk: add support for max open/active zone limit
 for zoned devices

On 2020/08/28 19:06, Niklas Cassel wrote:
> On Fri, Aug 28, 2020 at 07:06:26AM +0000, Damien Le Moal wrote:
>> On 2020/08/27 22:50, Niklas Cassel wrote:
>>> Add support for user space to set a max open zone and a max active zone
>>> limit via configfs. By default, the default values are 0 == no limit.
>>>
>>> Call the block layer API functions used for exposing the configured
>>> limits to sysfs.
>>>
>>> Add accounting in null_blk_zoned so that these new limits are respected.
>>> Performing an operating that would exceed these limits results in a
>>
>> Performing a write operation that would result in exceeding these...
>>
>>> standard I/O error.
>>>
> 
> It is not only a write operation, also e.g. open zone operation.
> However I will s/Performing an operating/Performing an operation/
> 
>>> +/*
>>> + * This function matches the manage open zone resources function in the ZBC standard,
>>> + * with the addition of max active zones support (added in the ZNS standard).
>>> + *
>>> + * The function determines if a zone can transition to implicit open or explicit open,
>>> + * while maintaining the max open zone (and max active zone) limit(s). It may close an
>>> + * implicit open zone in order to make additional zone resources available.
>>> + *
>>> + * ZBC states that an implicit open zone shall be closed only if there is not
>>> + * room within the open limit. However, with the addition of an active limit,
>>> + * it is not certain that closing an implicit open zone will allow a new zone
>>> + * to be opened, since we might already be at the active limit capacity.
>>> + */
>>> +static bool null_manage_zone_resources(struct nullb_device *dev, struct blk_zone *zone)
>>
>> I still do not like the name. Since this return a bool, what about
>> null_has_zone_resources() ?
> 
> I also don't like the name :)
> 
> However, since the ZBC spec, in the descriptions of "Write operation, Finish
> operation, and Open operation", says that the "manage open zone resources"
> function must be called before each of these operations are performed,
> and that there is a section that defines how the "manage open zone resources"
> is defined, I was thinking that having a similar name would be of value.
> 
> And I agree that it is weird that it returns a bool, but that is how it is
> defined in the standard.
> 
> Perhaps it should have exactly the same name as the standard, i.e.
> null_manage_open_zone_resources() ?
> 
> However, if you don't think that there is any point of trying to have
> a similar name to the function in ZBC, then I will happily rename it :)

Well, I prefer to prioritize code readability over following a not-so-good name
that the standard chose. The function description makes it clear that it is zone
management a-la-ZBC, so a function name clarifying what is being checked is
better in my opinion. Not a blocker though. Feel free to chose what to do here.

Cheers.


-- 
Damien Le Moal
Western Digital Research