On Mon, Jan 22, 2024 at 03:27:48PM -0500, Steven Rostedt wrote: > From: "Steven Rostedt (Google)" <rost...@goodmis.org> > > The eventfs inodes and directories are allocated when referenced. But this > leaves the issue of keeping consistent inode numbers and the number is > only saved in the inode structure itself. When the inode is no longer > referenced, it can be freed. When the file that the inode was representing > is referenced again, the inode is once again created, but the inode number > needs to be the same as it was before. > > Just making the inode numbers the same for all files is fine, but that > does not work with directories. The find command will check for loops via > the inode number and having the same inode number for directories triggers: > > # find /sys/kernel/tracing > find: File system loop detected; > '/sys/kernel/debug/tracing/events/initcall/initcall_finish' is part of the > same file system loop as > '/sys/kernel/debug/tracing/events/initcall'. > [..] > > Linus pointed out that the eventfs_inode structure ends with a single > 32bit int, and on 64 bit machines, there's likely a 4 byte hole due to > alignment. We can use this hole to store the inode number for the > eventfs_inode. All directories in eventfs are represented by an > eventfs_inode and that data structure can hold its inode number. > > That last int was also purposely placed at the end of the structure to > prevent holes from within. Now that there's a 4 byte number to hold the > inode, both the inode number and the last integer can be moved up in the > structure for better cache locality, where the llist and rcu fields can be > moved to the end as they are only used when the eventfs_inode is being > deleted. > > Link: > https://lore.kernel.org/all/CAMuHMdXKiorg-jiuKoZpfZyDJ3Ynrfb8=x+c7x0eewxn-yr...@mail.gmail.com/ > > Reported-by: Geert Uytterhoeven <ge...@linux-m68k.org> > Fixes: 53c41052ba31 ("eventfs: Have the inodes all for files and directories > all be the same") > Signed-off-by: Steven Rostedt (Google) <rost...@goodmis.org>
Since I reviewed the earlier patch, I will repeat here for the formal one too. :) Thanks for avoiding the hashing! Reviewed-by: Kees Cook <keesc...@chromium.org> -- Kees Cook
