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

Message-ID: <20260209095038.50e62eda@pumpkin>
Date: Mon, 9 Feb 2026 09:50:38 +0000
From: David Laight <david.laight.linux@...il.com>
To: Ben Hutchings <ben@...adent.org.uk>
Cc: Gui-Dong Han <hanguidong02@...il.com>, 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 Sun, 08 Feb 2026 23:33:31 +0100
Ben Hutchings <ben@...adent.org.uk> wrote:

> On Sun, 2026-02-08 at 11:48 +0000, David Laight wrote:
> > On Sat, 07 Feb 2026 12:43:29 +0100
> > Ben Hutchings <ben@...adent.org.uk> wrote:
> >   
> > > 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.  
> > 
> > Look at the alpha version and the arm64 LTO code.
> > The latter changes the reads to have 'acquire' semantics to stop re-ordering.
> > Needed for LTO, but the thought is it might be needed in other cases.  
> [...]
> 
> Oh, so they do.  Sorry for "correcting" you based on my old information.

I'm not at all sure that the field which just need protection from TOCTOU
and load/store tearing shouldn't just be marked volatile.
ISTR that part of the original objection was that not all accesses needed
it - but the static check code seems to be enforcing that now.
Marking things volatile mostly stops the compiler doing CSE - which is
exactly what you want here.

	David


> 
> Ben.
>