On 2021/06/10 1:49, Bart Van Assche wrote:
> On 6/8/21 9:40 PM, Damien Le Moal wrote:
>> On 2021/06/09 8:07, Bart Van Assche wrote:
>
> [ ... ]
>
>>> +/*
>>> + * The accepted I/O priority values are 0..IOPRIO_CLASS_MAX(3). 0 (default)
>>> + * means do not modify the I/O priority. Values 1..3 are used to restrict the
>>> + * I/O priority for a cgroup to the specified priority. See also
>>> + * <linux/ioprio.h>.
>>> + */
>>> +#define IOPRIO_CLASS_MAX IOPRIO_CLASS_IDLE
>
> [ ... ]
>
>>> +static int ioprio_set_prio_class(struct cgroup_subsys_state *css,
>>> + struct cftype *cft, u64 val)
>>> +{
>>> + struct ioprio_blkcg *blkcg = ioprio_blkcg_from_css(css);
>>> +
>>> + if (val > IOPRIO_CLASS_MAX)
>>> + return -EINVAL;
>>
>> Where is IOPRIO_CLASS_MAX defined ? I do not see it.
>
> Near the start of the new block/blk-ioprio.c file.
OK. I missed that. Shouldn't this definition be moved to include/linux/ioprio.h
? It can be added as the last entry of the class enum.
>
>> Why not use ioprio_valid() ?
>
> The definition of that macro is as follows:
>
> #define ioprio_valid(mask) \
> (IOPRIO_PRIO_CLASS((mask)) != IOPRIO_CLASS_NONE)
>
> So that macro accepts I/O priority classes 1..7 while the above code
> accepts I/O priority classes 0..3. I think that ioprio_set_prio_class()
> should only accept I/O priority class values 0..3.
Yes. I misread this macro definition. The name is actually confusing. It does
not check that the ioprio is valid, it only check that it is not NONE, meaning
that something is set, but that something may not be valid. We could probably
turn this macro into an inline function that does a better job at checking that
valid values are in the "mask" argument, which by the way is also badly named,
since that is not a mask at all, but an ioprio.
--
Damien Le Moal
Western Digital Research
