Re: [PATCH v2 2/4] block: fix ioprio interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/6/21 8:57 AM, Damien Le Moal wrote:
> On 2021/08/06 15:35, Hannes Reinecke wrote:
>> On 8/6/21 7:11 AM, Damien Le Moal wrote:
>>> An iocb aio_reqprio field is 16-bits (u16) but often handled as an int
>>> in the block layer. E.g. ioprio_check_cap() takes an int as argument.
>>> With such implicit int casting function calls, the upper 16-bits of the
>>> int argument may be left uninitialized by the compiler, resulting in
>>> invalid values for the IOPRIO_PRIO_CLASS() macro (garbage upper bits)
>>> and in an error return for functions such as ioprio_check_cap().
>>>
>>> Fix this by masking the result of the shift by IOPRIO_CLASS_SHIFT bits
>>> in the IOPRIO_PRIO_CLASS() macro. The new macro IOPRIO_CLASS_MASK
>>> defines the 3-bits mask for the priority class.
>>>
>>> While at it, cleanup the following:
>>> * Apply the mask IOPRIO_PRIO_MASK to the data argument of the
>>>    IOPRIO_PRIO_VALUE() macro to ignore upper bits of the data value.
>>> * Remove unnecessary parenthesis around fixed values in the macro
>>>    definitions in include/uapi/linux/ioprio.h.
>>> * Update the outdated mention of CFQ in the comment describing priority
>>>    classes and instead mention BFQ and mq-deadline.
>>> * Change the argument name of the IOPRIO_PRIO_CLASS() and
>>>    IOPRIO_PRIO_DATA() macros from "mask" to "ioprio" to reflect the fact
>>>    that an IO priority value should be passed rather than a mask.
>>> * Change the ioprio_valid() macro into an inline function, adding a
>>>    check on the maximum value of the class of a priority value as
>>>    defined by the IOPRIO_CLASS_MAX enum value. Move this function to
>>>    the kernel side in include/linux/ioprio.h.
>>> * Remove the unnecessary "else" after the return statements in
>>>    task_nice_ioclass().
>>>
>>> Signed-off-by: Damien Le Moal <damien.lemoal@xxxxxxx>
>>> ---
>>>   include/linux/ioprio.h      | 15 ++++++++++++---
>>>   include/uapi/linux/ioprio.h | 19 +++++++++++--------
>>>   2 files changed, 23 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/include/linux/ioprio.h b/include/linux/ioprio.h
>>> index ef9ad4fb245f..9b3a6d8172b4 100644
>>> --- a/include/linux/ioprio.h
>>> +++ b/include/linux/ioprio.h
>>> @@ -8,6 +8,16 @@
>>>   
>>>   #include <uapi/linux/ioprio.h>
>>>   
>>> +/*
>>> + * Check that a priority value has a valid class.
>>> + */
>>> +static inline bool ioprio_valid(unsigned short ioprio)
>>
>> Wouldn't it be better to use 'u16' here as type, as we're relying on the 
>> number of bits?
> 
> Other functions in block/ioprio.c and in include/linux/ioprio.h use "unsigned
> short", so I followed. But many functions, if not most, use "int". This is all a
> bit of a mess. I think we need a "typedef ioprio_t u16;" to clean things up. But
> there are a lot of places to fix. I can add such patch... Worth it ?
> 
Possibly not.
Consider my comment retracted :-)

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@xxxxxxx			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux