linux-kernel - Re: [PATCH v4] fs: hide names_cachep behind runtime access machinery

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAGudoHE-9R0ZfFk-bE9TBhejkmZE3Hu2sT0gGiy=i_1_He=9GA@mail.gmail.com>
Date: Fri, 31 Oct 2025 16:13:25 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Christian Brauner <brauner@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Thomas Gleixner <tglx@...utronix.de>, 
	viro@...iv.linux.org.uk, jack@...e.cz, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, pfalcato@...e.de
Subject: Re: [PATCH v4] fs: hide names_cachep behind runtime access machinery

On Fri, Oct 31, 2025 at 1:08 PM Christian Brauner <brauner@...nel.org> wrote:
>
> > I wonder if it would make sense to bypass the problem by moving the
> > pathname handling routines to a different header -- might be useful in
> > its own right to slim down the kitchen sink that fs.h turned out to
> > be, but that's another bikeshed-y material.
>
> fs.h needs to be split up. It's on my ToDo but let's just say there's a
> lot of stuff on it so it's not really high-priority. If you have a good
> reason to move something out of there by my guest. It would be
> appreciated!

I slept on it and I think the pragmatic way forward is to split up
runtime-const.h instead.

The code to emit patchable access has very little requirements in
terms header files. In contrast, the code to do the patching can pull
in all kinds of headers with riscv being a great example.

While I ran into problems with fs.h on riscv specifically, one has to
expect the pre-existing mess will be posing an issue in other places
should they try to use the machinery.

So I think runtime-const-accessors.h (pardon the long name) for things
like fs.h would be the way forward, regardless of what happens with
the latter in the long run. I'm going to hack it up later.