[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiq5mr+wSb6pmtt7QqBhQo_xr7ip=yMwQ5ryWVwCyMhfg@mail.gmail.com>
Date: Mon, 22 Jan 2024 09:37:49 -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 08:46, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> I can add this patch to make sure directory inodes are unique, as it causes
> a regression in find, but keep the file inodes the same.
Yeah, limiting it to directories will at least somewhat help the
address leaking.
However, I also note that you never did the "set i_nlink to one"
trick, which is the traditional thing to do to tell 'find' that it
cannot do its directory optimization thing.
I'm not sure that the nlink trick disables this part of the find
sanity checks, but the *first* thing to check would be something like
this
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -182,6 +182,7 @@ static int tracefs_getattr(struct mnt_idmap *idmap,
set_tracefs_inode_owner(inode);
generic_fillattr(idmap, request_mask, inode, stat);
+ stat->nlink = 1;
return 0;
}
because it might just fix the issue.
Having nlink == 1 is how non-unix filesystems (like FAT etc) indicate
that you can't try to count directory entries to optimize traversal.
And it is possible that that is where the whole find thing comes from,
but who knows, it could be a generic loop detector that runs
independently of the usual link detection.
Linus
Powered by blists - more mailing lists