[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiLqJYT2GGSBhKuJS-Uq1DVq3S32oP0SwqQiATuBivxcg@mail.gmail.com>
Date: Mon, 22 Jan 2024 10:19:12 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>, Kees Cook <keescook@...omium.org>,
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>, Christian Brauner <brauner@...nel.org>,
Al Viro <viro@...iv.linux.org.uk>, Ajay Kaher <ajay.kaher@...adcom.com>
Subject: Re: [for-linus][PATCH 1/3] eventfs: Have the inodes all for files and
directories all be the same
On Mon, 22 Jan 2024 at 09:39, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Actually, why not juist add an inode number to your data structures,
> at least for directories? And just do a static increment on it as they
> get registered?
>
> That avoids the whole issue with possibly leaking kernel address data.
The 'nlink = 1' thing doesn't seem to make 'find' any happier for this
case, sadly.
But the inode number in the 'struct eventfs_inode' looks trivial. And
doesn't even grow that structure on 64-bit architectures at least,
because the struct is already 64-bit aligned, and had only one 32-bit
entry at the end.
On 32-bit architectures the structure size grows, but I'm not sure the
allocation size grows. Our kmalloc() is quantized at odd numbers.
IOW, this trivial patch seems to be much safer than worrying about
some pointer exposure.
Linus
View attachment "patch.diff" of type "text/x-patch" (1593 bytes)
Powered by blists - more mailing lists