On Tue, Feb 07, 2023 at 09:14:08PM +0800, Dawei Li wrote:
> Structures marked with __randomize_layout are supposed to reorder layout
> of members randomly. Although layout is not guranteed to be reordered
> since dependency on hardening config, but let's not make assumption such
> as "member foo is first".
>
> Signed-off-by: Dawei Li <set_pte_at@xxxxxxxxxxx>
> ---
> include/linux/fs.h | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index c1769a2c5d70..9114c4e44154 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -585,11 +585,6 @@ is_uncached_acl(struct posix_acl *acl)
>
> struct fsnotify_mark_connector;
>
> -/*
> - * Keep mostly read-only and often accessed (especially for
> - * the RCU path lookup and 'stat' data) fields at the beginning
> - * of the 'struct inode'
> - */
> struct inode {
> umode_t i_mode;
> unsigned short i_opflags;
> @@ -1471,7 +1466,7 @@ struct sb_writers {
> };
>
> struct super_block {
> - struct list_head s_list; /* Keep this first */
> + struct list_head s_list;
If these comments are just talking about how the fields are arranged for best
performance (the inode comment definitely is; the super_block one is a bit
ambiguous), rather than for correctness, they are perfectly fine to keep. It
still makes sense to do those sort of manual structure layout optimizations on
commonly used structures like these, because they still benefit everyone who
doesn't have CONFIG_RANDSTRUCT enabled (i.e., almost everyone).
- Eric
