Re: [PATCH] i2c: designware: Fix corrupted memory seen in the ISR

[Yann Sionneau]

On 13/09/2023 13:32, Yann Sionneau wrote:
> On 13/09/2023 13:22, Andy Shevchenko wrote:
> > On Wed, Sep 13, 2023 at 11:04:00AM +0200, Yann Sionneau wrote:
> > > On 13/09/2023 03:03, Jan Bottorff wrote:
> > ...
> >
> > > > +    /*
> > > > +     * To guarantee data written by the current core is visible to
> > > > +     * all cores, a write barrier is required. This needs to be
> > > > +     * before an interrupt causes execution on another core.
> > > > +     * For ARM processors, this needs to be a DSB barrier.
> > > > +     */
> > > > +    wmb();
> > > Apart from the commit message it looks good to me.
> > >
> > > If I understand correctly without this wmb() it is possible that the 
> > > writes
> > > to dev->msg_write_idx , dev->msg_read_idx = 0 etc would not yet be 
> > > visible
> > > to another CPU running the ISR handler right after enabling those.
> > If this is the case, shouldn't we rather use READ_ONCE()/WRITE_ONCE() 
> > where
> > appropriate?
> To my knowledge the READ_ONCE()/WRITE_ONCE() only imply the use of 
> volatile to access memory thus preventing the compiler to do weird 
> optimizations like merging store/loads, moving store/loads, removing 
> them etc
>
> They don't imply a memory barrier.
>
> Some systems need a memory barrier, to emit a "fence" like 
> instruction, so that the pipeline stalls waiting for the store to 
> "finish", for systems where the writes are posted.
>
> Regards,
Well, for the READ_ONCE() actually I'm wrong, it's overloaded for Alpha 
and arm64 https://elixir.bootlin.com/linux/latest/C/ident/__READ_ONCE

--

Yann