linux-kernel - Re: [PATCH] fs: mark lookup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGudoHHzXjvMXUZhCKMvdPxzwg71MOAUT+8c6qgiKhUfS0UoNA@mail.gmail.com>
Date: Tue, 25 Nov 2025 10:54:25 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Christian Brauner <brauner@...nel.org>
Cc: viro@...iv.linux.org.uk, jack@...e.cz, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] fs: mark lookup_slow() as noinline

On Tue, Nov 25, 2025 at 10:05 AM Christian Brauner <brauner@...nel.org> wrote:
>
> On Wed, Nov 19, 2025 at 03:49:30PM +0100, Mateusz Guzik wrote:
> > Otherwise it gets inlined notably in walk_component(), which convinces
> > the compiler to push/pop additional registers in the fast path to
> > accomodate existence of the inlined version.
> >
> > Shortens the fast path of that routine from 87 to 71 bytes.
> >
> > Signed-off-by: Mateusz Guzik <mjguzik@...il.com>
> > ---
>
> Fwiw, the biggest problem is that we need to end up with something
> obvious so that we don't accidently destroy any potential performance
> gain in say 2 years because everyone forgot why we did things this way.
>

I don't think there is a way around reviewing patches with an eye on
what they are doing to the fast path, on top of periodically checking
if whatever is considered the current compiler decided to start doing
something funky with it.

I'm going to save a rant about benchmarking changes like these in the
current kernel for another day.