linux-kernel - Re: [PATCH] proc: rearrange struct proc_dir

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20171221062538.GA2059@avx2>
Date:   Thu, 21 Dec 2017 09:25:38 +0300
From:   Alexey Dobriyan <adobriyan@...il.com>
To:     Randy Dunlap <rdunlap@...radead.org>
Cc:     akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] proc: rearrange struct proc_dir_entry

On Wed, Dec 20, 2017 at 03:10:48PM -0800, Randy Dunlap wrote:
> On 12/20/2017 01:59 PM, Alexey Dobriyan wrote:
> > struct proc_dir_entry became bit messy over years:
> > 
> > * move 16-bit ->mode_t before namelen to get rid of padding
> > * make ->in_use first field: it seems to be most used resulting in
> >   smaller code on x86_64 (defconfig):
> > 
> > 	add/remove: 0/0 grow/shrink: 7/13 up/down: 24/-67 (-43)
> > 	Function                                     old     new   delta
> > 	proc_readdir_de                              451     455      +4
> > 	proc_get_inode                               282     286      +4
> > 	pde_put                                       65      69      +4
> > 	remove_proc_subtree                          294     297      +3
> > 	remove_proc_entry                            297     300      +3
> > 	proc_register                                295     298      +3
> > 	proc_notify_change                            94      97      +3
> > 	unuse_pde                                     27      26      -1
> > 	proc_reg_write                                89      85      -4
> > 	proc_reg_unlocked_ioctl                       85      81      -4
> > 	proc_reg_read                                 89      85      -4
> > 	proc_reg_llseek                               87      83      -4
> > 	proc_reg_get_unmapped_area                   123     119      -4
> > 	proc_entry_rundown                           139     135      -4
> > 	proc_reg_poll                                 91      85      -6
> > 	proc_reg_mmap                                 79      73      -6
> > 	proc_get_link                                 55      49      -6
> > 	proc_reg_release                             108     101      -7
> > 	proc_reg_open                                298     291      -7
> > 	close_pdeo                                   228     218     -10
> > 
> > * move writeable fields together to a first cacheline (on x86_64),
> >   those include
> > 	* ->in_use: reference count, taken every open/read/write/close etc
> > 	* ->count: reference count, taken at readdir on every entry
> > 	* ->pde_openers: tracks (nearly) every open, dirtied
> > 	* ->pde_unload_lock: spinlock protecting ->pde_openers
> > 	* ->proc_iops, ->proc_fops, ->data: writeonce fields,
> > 	  used right together with previous group.
> > 
> > * other rarely written fields go into 1st/2nd and 2nd/3rd cacheline on
> >   32-bit and 64-bit respectively.
> > 
> > Additionally on 32-bit, ->subdir, ->subdir_node, ->namelen, ->name
> > go fully into 2nd cacheline, separated from writeable fields.
> > They are all used during lookup.
> 
> Does
> >  } __randomize_layout;
> pay attention to any of that?

No. You can randomize inside cachelines but it will look rather ugly.
__randomize_layout rearranges everything.