[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240122143740.6a889e36@gandalf.local.home>
Date: Mon, 22 Jan 2024 14:37:40 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 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>, 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 13:27:25 -0500
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
> > IOW, this trivial patch seems to be much safer than worrying about
> > some pointer exposure.
>
> My only concern about the simple ino_counter static increment is what
> happens in the unlikely scenario of a 32-bit overflow. This is why
> I suggested using a bitmap to track inode allocation. It's compact, and
> we don't care that much about the linear bitmap scan overhead because
> it's far from being a fast path.
The original code use to get its inode via "get_next_ino()" I don't think
there's any reason not to just go back and do that again.
It can still overflow, but it's not anything new that couldn't have happen
to debugfs and tracefs over the last decade.
-- Steve
Powered by blists - more mailing lists