linux-kernel - Re: [PATCH v6 2/5] fs: Convert kiocb rw

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 for Android: free password hash cracker in your pocket

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

Message-ID: <58087b03-a3c7-93fd-d1ad-de77181e8806@kernel.dk>
Date:   Tue, 22 May 2018 10:30:36 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Goldwyn Rodrigues <rgoldwyn@...e.de>, adam.manzanares@....com,
        viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
        bcrl@...ck.org
Cc:     tglx@...utronix.de, mingo@...nel.org, pombredanne@...b.com,
        kstewart@...uxfoundation.org, gregkh@...uxfoundation.org,
        bigeasy@...utronix.de, jack@...e.cz, darrick.wong@...cle.com,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-aio@...ck.org, linux-api@...r.kernel.org, hch@...radread.org,
        jmoyer@...hat.com
Subject: Re: [PATCH v6 2/5] fs: Convert kiocb rw_hint from enum to u16

On 5/22/18 10:24 AM, Goldwyn Rodrigues wrote:
> 
> 
> On 05/22/2018 10:32 AM, Jens Axboe wrote:
>> On 5/22/18 9:07 AM, adam.manzanares@....com wrote:
>>> From: Adam Manzanares <adam.manzanares@....com>
>>>
>>> In order to avoid kiocb bloat for per command iopriority support, rw_hint
>>> is converted from enum to a u16. Added a guard around ki_hint assignment.
>>>
>>> Signed-off-by: Adam Manzanares <adam.manzanares@....com>
>>> Reviewed-by: Christoph Hellwig <hch@....de>
>>> ---
>>>  include/linux/fs.h | 13 +++++++++++--
>>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>>> index 7f07977bdfd7..50de40dbbb85 100644
>>> --- a/include/linux/fs.h
>>> +++ b/include/linux/fs.h
>>> @@ -284,6 +284,8 @@ enum rw_hint {
>>>  	WRITE_LIFE_EXTREME	= RWH_WRITE_LIFE_EXTREME,
>>>  };
>>>  
>>> +#define MAX_KI_HINT		((1 << 16) - 1) /* ki_hint type is u16 */
>>
>> Instead of having to do this and now rely on those now being synced,
>> how about something like the below.
>>
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index 760d8da1b6c7..070438d0b62d 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -299,7 +299,7 @@ struct kiocb {
>>  	void (*ki_complete)(struct kiocb *iocb, long ret, long ret2);
>>  	void			*private;
>>  	int			ki_flags;
>> -	enum rw_hint		ki_hint;
>> +	u16			ki_hint;
>>  } __randomize_layout;
>>  
>>  static inline bool is_sync_kiocb(struct kiocb *kiocb)
>> @@ -1927,12 +1927,22 @@ static inline enum rw_hint file_write_hint(struct file *file)
>>  
>>  static inline int iocb_flags(struct file *file);
>>  
>> +static inline u16 ki_hint_validate(enum rw_hint hint)
>> +{
>> +	typeof(((struct kiocb *)0)->ki_hint) max_hint = -1;
> 
> This looks complex to me. Would force a reader to lookback at what
> datatype ki_hint is. I'd prefer to declare it as u16 max_hint = -1, or
> even the previous #define MAX_KI_HINT format is easier to read. Just a
> program reading style you are comfortable with though.

How is it complex? It's defining a type that'll be the same as ki_hint
in the kiocb, which is _exactly_ what we care about. Any sort of other
definition will rely on those two locations now being synced. The
above will never break.

So I strongly disagree. The above will _never_ require the reader to
figure out what the type is. Any other variant will _always_ require
the reader to check if they are the same.

-- 
Jens Axboe