linux-kernel - Re: [RFC][alpha] saner vmalloc handling (was Re: [Bug report] hash_name() may cross page boundary and trigger sleep in RCU context)

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+=Fv5QNL6q5vioEd8D9UqN10yM=EP1sMtYKYda5PoRqXngaQQ@mail.gmail.com>
Date: Sun, 30 Nov 2025 19:14:09 +0100
From: Magnus Lindholm <linmag7@...il.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: david laight <david.laight@...box.com>, Linus Torvalds <torvalds@...ux-foundation.org>, 
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org, 
	linux-alpha@...r.kernel.org
Subject: Re: [RFC][alpha] saner vmalloc handling (was Re: [Bug report]
 hash_name() may cross page boundary and trigger sleep in RCU context)

On Sun, Nov 30, 2025 at 5:43 PM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> On Sun, Nov 30, 2025 at 11:32:13AM +0000, david laight wrote:
>
> > How difficult would it be to allocate the pte for the next 8GB on demand
> > inside vmalloc(), and then propagate it to the per-task page tables.
> > That is a path than can sleep, so being slow if it needs to synchronise
> > with other cpu shouldn't matter - especially since it won't happen often.
> >
> > That should be moderately generic code and would let the vmalloc limit
> > be 'soft'; perhaps based on physical memory size, and even be raisable
> > from a sysctl.
>
> Considerable headache and pretty pointless, at that.  Note that >8G vmalloc
> space on alpha had been racy all along (and known to be that); it was
> basically "could we squeeze more out of khttpd" kind of fun.
>
> Do we have realistic vmalloc-crazy loads with high fragmentation of vmalloc
> space and total footprint worth bothering with that?

Hi everyone,

In my opinion, for Alpha I’d prefer the static preallocation model, as
it fixes the LARGE_VMALLOC race cleanly and keeps the fault path
straightforward. I don’t see many realistic Alpha workloads that would
benefit from a more complex or dynamic vmalloc setup, and compile-time
adjustment seems sufficient. Al’s version solves the issues without
adding new moving parts, which feels like the right tradeoff. Removing
code that has never worked properly should not cause any harm.

FWIW, I applied Al's patch and I'm running it now on my XP1000.
Seems to work as-is.

Regards

Magnus