linux-kernel - Re: [PATCH v4 24/35] vdso/datastore: Allocate data pages dynamically

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: <20251105153426.16228C13-hca@linux.ibm.com>
Date: Wed, 5 Nov 2025 16:34:26 +0100
From: Heiko Carstens <hca@...ux.ibm.com>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: Andy Lutomirski <luto@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Arnd Bergmann <arnd@...db.de>, "David S. Miller" <davem@...emloft.net>,
        Andreas Larsson <andreas@...sler.com>,
        Nick Alcock <nick.alcock@...cle.com>, John Stultz <jstultz@...gle.com>,
        Stephen Boyd <sboyd@...nel.org>,
        John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
        Shuah Khan <shuah@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, "Theodore Ts'o" <tytso@....edu>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Russell King <linux@...linux.org.uk>,
        Madhavan Srinivasan <maddy@...ux.ibm.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Nicholas Piggin <npiggin@...il.com>,
        Christophe Leroy <christophe.leroy@...roup.eu>,
        Huacai Chen <chenhuacai@...nel.org>, WANG Xuerui <kernel@...0n.name>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Sven Schnelle <svens@...ux.ibm.com>,
        Nagarathnam Muthusamy <nagarathnam.muthusamy@...cle.com>,
        Shannon Nelson <sln@...main.com>, linux-kernel@...r.kernel.org,
        sparclinux@...r.kernel.org, linux-kselftest@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linuxppc-dev@...ts.ozlabs.org,
        loongarch@...ts.linux.dev, linux-mips@...r.kernel.org,
        linux-s390@...r.kernel.org
Subject: Re: [PATCH v4 24/35] vdso/datastore: Allocate data pages dynamically

On Tue, Oct 14, 2025 at 08:49:10AM +0200, Thomas Weißschuh wrote:
> Allocating the datapages as part of the kernel image does not work on
> SPARC. It is also problematic with regards to dcache aliasing as there is
> no guarantee that the virtual addresses used by the kernel are compatible
> with those used by userspace.
> 
> Allocate the data pages through the page allocator instead.
> Unused pages in the vDSO VMA are still allocated to keep the virtual
> addresses aligned.
> 
> These pages are used by both the timekeeping, random pool and architecture
> initialization code. Introduce a new early initialization step, to make
> sure they are available when needed.
> 
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> Tested-by: Andreas Larsson <andreas@...sler.com>
> Reviewed-by: Andreas Larsson <andreas@...sler.com>
> ---
>  include/linux/vdso_datastore.h |  6 ++++++
>  init/main.c                    |  2 ++
>  lib/vdso/datastore.c           | 44 ++++++++++++++++++++++--------------------
>  3 files changed, 31 insertions(+), 21 deletions(-)

...

> +void __init vdso_setup_data_pages(void)
> +{
> +	unsigned int order = get_order(VDSO_NR_PAGES * PAGE_SIZE);
> +	struct folio *folio = folio_alloc(GFP_KERNEL, order);

I'm seeing random hangs on s390 too with our CI, but unfortunately I cannot
reproduce it manually. But looking at one of the dumps it looks to me like the
vdso time page contains (more or less) random junk at the end. Or in other
words, shouldn't this be:

	struct folio *folio = folio_alloc(GFP_KERNEL | __GFP_ZERO, order);

? At least that is a difference to before as far as I can tell.