On Thu, Nov 7, 2019 at 10:22 AM Alexander Potapenko <glider@xxxxxxxxxx> wrote:
> On Thu, Nov 7, 2019 at 10:04 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > On Thu, Nov 7, 2019 at 7:08 AM Sergey Senozhatsky
> > <sergey.senozhatsky.work@xxxxxxxxx> wrote:
> > >
> > > Yeah, 'volatile' in this case will do what it sort of meant to do - prevent
> > > compiler optimizations. So, like you said, it's not a synchronization issue
> > > and we don't 'volatile' data structures.
> >
> > The normal way to do a volatile access would be
> > READ_ONCE()/WRITE_ONCE(), but that seems stronger than
> > the barrier() here. I'd just stick to adding a barrier.
> I actually like the READ_ONCE idea more, as READ_ONCE is really a
> documented way to prevent the compiler from merging reads, which is
> what we want here.
Fair enough.
> I also thought that the original barrier() statement was just a
> compiler barrier, which didn't introduce any additional CPU
> instructions.
> Turns out I was wrong, and barrier() also serves as a memory barrier.
The definition of barrier is
#define barrier() __asm__ __volatile__("": : :"memory")
which is no actual barrier instruction but is a full barrier to the compiler.
Only for the Intel ecc compiler it is defined as an intrinsic that I don't
know.
Arnd
