[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240625-dinosaurier-keramik-f04310167065@brauner>
Date: Tue, 25 Jun 2024 10:05:47 +0200
From: Christian Brauner <brauner@...nel.org>
To: Xi Ruoyao <xry111@...111.site>
Cc: Mateusz Guzik <mjguzik@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>, Alexander Viro <viro@...iv.linux.org.uk>,
Jan Kara <jack@...e.cz>, Steven Rostedt <rostedt@...dmis.org>,
Masami Hiramatsu <mhiramat@...nel.org>, Alejandro Colomar <alx@...nel.org>,
Arnd Bergmann <arnd@...db.de>, Huacai Chen <chenhuacai@...ngson.cn>,
Xuerui Wang <kernel@...0n.name>, Jiaxun Yang <jiaxun.yang@...goat.com>,
Icenowy Zheng <uwu@...nowy.me>, linux-fsdevel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, linux-arch@...r.kernel.org, loongarch@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vfs: Add AT_EMPTY_PATH_NOCHECK as unchecked AT_EMPTY_PATH
On Sat, Jun 22, 2024 at 03:41:19PM GMT, Linus Torvalds wrote:
> On Sat, 22 Jun 2024 at 14:25, Mateusz Guzik <mjguzik@...il.com> wrote:
> >
> > +cc Linus
>
> Thanks.
>
> > To sum up the problem: stat and statx met with "" + AT_EMPTY_PATH have
> > more work to do than fstat and its hypotethical statx counterpart:
> > - buf alloc/free for the path
> > - userspace access (very painful on x86_64 + SMAP)
> > - lockref acquire/release
>
> Yes. That LOOKUP_EMPTY_NOCHECK is *not* the fix.
I have explicitly NAKed an approach like this months ago in [1]. So I'm
not sure why we're getting that patch in the first place tbh.
[1]: https://lore.kernel.org/lkml/599df4a3-47a4-49be-9c81-8e21ea1f988a@xen0n.name
Powered by blists - more mailing lists