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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 19 Oct 2021 15:58:36 +0200 From: Jan Kara <jack@...e.cz> To: Gabriel Krisman Bertazi <krisman@...labora.com> Cc: jack@...e.com, amir73il@...il.com, djwong@...nel.org, tytso@....edu, david@...morbit.com, dhowells@...hat.com, khazhy@...gle.com, linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org, linux-api@...r.kernel.org, kernel@...labora.com, Jan Kara <jack@...e.cz> Subject: Re: [PATCH v8 23/32] fanotify: Wrap object_fh inline space in a creator macro On Mon 18-10-21 21:00:06, Gabriel Krisman Bertazi wrote: > fanotify_error_event would duplicate this sequence of declarations that > already exist elsewhere with a slight different size. Create a helper > macro to avoid code duplication. > > Suggested-by: Jan Kara <jack@...e.cz> > Signed-off-by: Gabriel Krisman Bertazi <krisman@...labora.com> > > --- > Among the suggestions, I think this is simpler because it avoids > deep nesting the variable-sized attribute, which would have been hidden > inside fee->ffe->object_fh.buf. One nit from me as well :) > +#define FANOTIFY_INLINE_FH(size) \ > +struct { \ > + struct fanotify_fh object_fh; \ > + /* Space for object_fh.buf[] - access with fanotify_fh_buf() */ \ > + unsigned char _inline_fh_buf[(size)]; \ > +} > + Can the macro perhaps take the name of the fanotify_fh member it creates? Like: #define FANOTIFY_INLINE_FH(name, size) Harcoding _inline_fh_buf is fine since it isn't ever used directly but hardcoding object_fh looks ugly to me. With that improved feel free to add: Reviewed-by: Jan Kara <jack@...e.cz> Honza -- Jan Kara <jack@...e.com> SUSE Labs, CR
Powered by blists - more mailing lists