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: <CAGudoHFC9vfHZsgjvib=Hy8wNom27wYG+iJz=5G_6zNQHF2ndA@mail.gmail.com>
Date: Fri, 31 Oct 2025 17:25:03 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Christian Brauner <brauner@...nel.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 5:04 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Fri, 31 Oct 2025 at 08:13, Mateusz Guzik <mjguzik@...il.com> wrote:
> >
> > I slept on it and I think the pragmatic way forward is to split up
> > runtime-const.h instead.
>
> I don't think that would be wrong, but I do think the real bug was to
> include runtime-const.h in any headers at all.
>

I think that was the right call, just that realities of going past
amd64 caught up with the header mixing the dependency-lean (if you
will) access with dependency-heavy patching of it.

Again with names_cachep as an example: there are different spots which
use it. On paper, fs.h can include the right header(tm) and everyone
is transparently covered. Without that every single .c file has to be
adjusted.

But that's only few spots, so one could argue that's a minor inconvenience.

Suppose one was trying to make systemic use of of the machinery for
other stuff. For sake of argument, say everything marked
ro_after_init?

With a lean header it will be feasible to sneak it in to something de
facto included everywhere.

[snip]
> End result: I think your patch to just use
>
>   #ifdef MODULE
>
> in the header was the right one. Except instead of that
>
> +#ifdef MODULE
> +#define __USER_PTR_MAX USER_PTR_MAX
> +#else
>
> thing, I think the right thing to do is to just do
>
>   #ifdef MODULE
>    #include <asm-generic/runtime-const.h>
>    #undef runtime_const_init
>  #else
>    #include <asm/runtime-const.h>
>   #endif
>
> in the x86 uaccess_64.h header file.
>

While I can concede __USER_PTR_MAX naming is not the best here, I
think your approach looks weird but it also complicates things.

I take the intent would be still to fail compilation if
runtime-const.h is included. The file is there for the premier
platforms, but most platforms still resort to
asm-generic/runtime-const.h. I think it would be beneficial to have
that sucker also cause compilation failure if included for a module.
That way someone developing on a non-mainstream platform is less
likely to post a patch bogus on this front.

> Let me think about this a bit more, but I feel really bad about having
> missed this bug. I'm relieved to say that it looks largely harmless in
> practice, but it really is me having royally messed up.
>

Sure, there is no rush whatsoever. The original patch was meant to be
a 5 minute detour and it is not holding up any work.