Re: [PATCH v6 2/5] fs: Convert kiocb rw_hint from enum to u16

On 5/22/18 9:30 AM, Jens Axboe wrote:

On 5/22/18 10:24 AM, Goldwyn Rodrigues wrote:

quoted

On 05/22/2018 10:32 AM, Jens Axboe wrote:

quoted

On 5/22/18 9:07 AM, adam.manzanares@wdc.com wrote:

quoted

From: Adam Manzanares <redacted>

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 <redacted>
Reviewed-by: Christoph Hellwig <hch@lst.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.

I do think the previous code was a bit easier to parse at first glance, 
but that is outweighed by the fact that the validate function is now 
directly tied to the kiocb ki_hint type.

I also missed one spot where I should have used ki_hint_validate. Will 
resend soon.