linux-kernel - Re: [PATCH] hwmon: (max16065) Use READ/WRITE_ONCE to avoid compiler optimization induced race

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: <f6710a1f44d2b32df1cb9b09cddc6695bf76eec2.camel@decadent.org.uk>
Date: Sat, 07 Feb 2026 12:43:29 +0100
From: Ben Hutchings <ben@...adent.org.uk>
To: David Laight <david.laight.linux@...il.com>, Gui-Dong Han
	 <hanguidong02@...il.com>
Cc: linux@...ck-us.net, linux-hwmon@...r.kernel.org, 
	linux-kernel@...r.kernel.org, baijiaju1990@...il.com, stable@...r.kernel.org
Subject: Re: [PATCH] hwmon: (max16065) Use READ/WRITE_ONCE to avoid compiler
 optimization induced race

On Sat, 2026-02-07 at 10:43 +0000, David Laight wrote:
> On Tue,  3 Feb 2026 20:14:43 +0800
> Gui-Dong Han <hanguidong02@...il.com> wrote:
> 
> > Simply copying shared data to a local variable cannot prevent data
> > races. The compiler is allowed to optimize away the local copy and
> > re-read the shared memory, causing a Time-of-Check Time-of-Use (TOCTOU)
> > issue if the data changes between the check and the usage.
> 
> While the compiler is allowed to do this, is there any indication
> that either gcc or clang have ever done it?
> ISTR someone saying that they never did - although I thought that
> was the original justification for adding ACCESS_ONCE().

They do it sometimes and it's precisely why these maros were added.  It
makes no sense to me to look at what these compilers currrently do (for
some particular versions, optimisation settings, and targets) and
extrapolate that to the assertion that they will never optimise away a
copy.

> READ_ONCE() also includes barriers to guarantee ordering between cpu.
> These are empty on x86 but add code to architectures where the cpu
> can (IIRC) re-order writes.
> This is worst on alpha but affects arm and probably ppc.

No, READ_ONCE() and WRITE_ONCE() don't include any CPU memory barriers.

> For these cases is it enough to add the compile-time barrier() after
> reading the variable to a local.
> That will also generate better code on x86.
> 
> The WRITE_ONCE() aren't needed at all, the compilers definitely
> guarantee to do a single memory access for aligned accesses that are
> less than the size of a word.

I think in this case WRITE_ONCE() might not be needed, but it's also
harmless and it's much easier to reason about {READ,WRITE}_ONCE() being
paired up.

> This all stinks of being an AI generated patch.

This is a follow-up to an earlier patch that claimed to fix the TOCTOU
issue.  I objected to that because in the absense of READ_ONCE() it was
not guaranteed to do so.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)