linux-kernel - Re: [PATCH v2 1/3] arm64: Fix non-atomic __READ_ONCE() with CONFIG

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: <CANpmjNOBD5EX2vkVQoGq2v3xoTd+edcoz2g6n6u4fvahA3AXdA@mail.gmail.com>
Date: Thu, 29 Jan 2026 02:32:41 +0100
From: Marco Elver <elver@...gle.com>
To: Boqun Feng <boqun@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>, Will Deacon <will@...nel.org>, 
	Ingo Molnar <mingo@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Boqun Feng <boqun.feng@...il.com>, 
	Waiman Long <longman@...hat.com>, Bart Van Assche <bvanassche@....org>, llvm@...ts.linux.dev, 
	Catalin Marinas <catalin.marinas@....com>, Arnd Bergmann <arnd@...db.de>, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	stable@...r.kernel.org
Subject: Re: [PATCH v2 1/3] arm64: Fix non-atomic __READ_ONCE() with CONFIG_LTO=y

On Thu, 29 Jan 2026 at 02:21, Boqun Feng <boqun@...nel.org> wrote:
>
> On Thu, Jan 29, 2026 at 01:52:32AM +0100, Marco Elver wrote:
> > The implementation of __READ_ONCE() under CONFIG_LTO=y incorrectly
> > qualified the fallback "once" access for types larger than 8 bytes,
> > which are not atomic but should still happen "once" and suppress common
> > compiler optimizations.
> >
> > The cast `volatile typeof(__x)` applied the volatile qualifier to the
> > pointer type itself rather than the pointee. This created a volatile
> > pointer to a non-volatile type, which violated __READ_ONCE() semantics.
> >
> > Fix this by casting to `volatile typeof(*__x) *`.
>
> I guess a `volatile typeof(x) *` also works. Either way, good catch!

x might expand to some big expression, so better to refer to it only
once, and then use the same-typed *__x as a proxy. Semantically the
same, but compile-times ought to be better this way.

> Reviewed-by: Boqun Feng <boqun@...nel.org>

Thanks!