[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMuHMdV4sfj09jAPJ1Rc4B_ikSVNLaPUcK0xUX0O3N5uaZeJ+A@mail.gmail.com>
Date: Tue, 23 Jan 2024 10:16:50 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-kernel@...r.kernel.org, Masami Hiramatsu <mhiramat@...nel.org>,
Mark Rutland <mark.rutland@....com>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Andrew Morton <akpm@...ux-foundation.org>, Linus Torvalds <torvalds@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>
Subject: Re: [for-linus][PATCH 2/2] eventfs: Save directory inodes in the
eventfs_inode structure
On Tue, Jan 23, 2024 at 4:13 AM Steven Rostedt <rostedt@...dmis.org> wrote:
> From: "Steven Rostedt (Google)" <rostedt@...dmis.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-YRdCA@mail.gmail.com/
> Link: https://lore.kernel.org/linux-trace-kernel/20240122152748.46897388@gandalf.local.home
>
> Cc: Masami Hiramatsu <mhiramat@...nel.org>
> Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Reported-by: Geert Uytterhoeven <geert@...ux-m68k.org>
> Fixes: 53c41052ba31 ("eventfs: Have the inodes all for files and directories all be the same")
> Signed-off-by: Steven Rostedt (Google) <rostedt@...dmis.org>
> Reviewed-by: Kees Cook <keescook@...omium.org>
Tested-by: Geert Uytterhoeven <geert+renesas@...der.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68korg
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists