[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251110094145-462671cc-1f51-466a-b448-3dc541e764ca@linutronix.de>
Date: Mon, 10 Nov 2025 09:45:50 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: "Jason A. Donenfeld" <Jason@...c4.com>
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>,
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>,
Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>,
Alexander Gordeev <agordeev@...ux.ibm.com>, Christian Borntraeger <borntraeger@...ux.ibm.com>,
Sven Schnelle <svens@...ux.ibm.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 v5 17/34] random: vDSO: remove ifdeffery
On Sat, Nov 08, 2025 at 12:37:15AM +0100, Jason A. Donenfeld wrote:
> On Thu, Nov 06, 2025 at 11:02:10AM +0100, Thomas Weißschuh wrote:
> > -#endif
> > + if (IS_ENABLED(CONFIG_VDSO_GETRANDOM))
> > + smp_store_release((unsigned long *)&vdso_k_rng_data->generation, next_gen + 1);
> > +
>
> This is possible because vdso_k_rng_data is now defined in the C source
> on all platforms and under all configurations, even if
> !CONFIG_VDSO_GETRANDOM means it's null? Whereas before, some config's
> headers didn't have this at all, so the #ifdef was necessary?
This is possible because vdso/datapage.h is now included unconditionally.
(Which was made possible by the previous cleanup patches in this series)
vdso_k_rng_data is only defined if CONFIG_VDSO_GETRANDOM=y but declared
unconditionally. If CONFIG_VDSO_GETRANDOM=n all references to the symbol
are optimized away by the compiler before the linker is invoked, so no
unresolved references are created.
> If so, can you mention this in the commit message?
Will do.
Thomas
Powered by blists - more mailing lists