Received-SPF: pass (google.com: domain of linux-kernel+bounces-34973-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240123030826.619242906@goodmis.org> <20240123031452.830697973@goodmis.org>
In-Reply-To: <20240123031452.830697973@goodmis.org>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Tue, 23 Jan 2024 10:16:50 +0100
Message-ID: <CAMuHMdV4sfj09jAPJ1Rc4B_ikSVNLaPUcK0xUX0O3N5uaZeJ+A@mail.gmail.com>
Subject: Re: [for-linus][PATCH 2/2] eventfs: Save directory inodes in the
 eventfs_inode structure
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, Masami Hiramatsu <mhiramat@kernel.org>, 
	Mark Rutland <mark.rutland@arm.com>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, 
	Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, 
	Kees Cook <keescook@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 23, 2024 at 4:13=E2=80=AFAM Steven Rostedt <rostedt@goodmis.org=
> wrote:
> From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
>
> The eventfs inodes and directories are allocated when referenced. But thi=
s
> 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 representin=
g
> is referenced again, the inode is once again created, but the inode numbe=
r
> 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 trigger=
s:
>
>   # find /sys/kernel/tracing
> find: File system loop detected;
> '/sys/kernel/debug/tracing/events/initcall/initcall_finish' is part of th=
e 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 b=
e
> moved to the end as they are only used when the eventfs_inode is being
> deleted.
>
> Link: https://lore.kernel.org/all/CAMuHMdXKiorg-jiuKoZpfZyDJ3Ynrfb8=3DX+c=
7x0Eewxn-YRdCA@mail.gmail.com/
> Link: https://lore.kernel.org/linux-trace-kernel/20240122152748.46897388@=
gandalf.local.home
>
> Cc: Masami Hiramatsu <mhiramat@kernel.org>
> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Fixes: 53c41052ba31 ("eventfs: Have the inodes all for files and director=
ies all be the same")
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> Reviewed-by: Kees Cook <keescook@chromium.org>

Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--=20
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
org

In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
                                -- Linus Torvalds