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

[David Laight <david.laight.linux@gmail.com>]

On Sat, 07 Feb 2026 12:43:29 +0100
Ben Hutchings <ben@decadent.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@gmail.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.

	David 

> 
> > 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.
>