On Mon, Nov 11, 2019 at 10:32:46AM +0100, Arnd Bergmann wrote:
> On Mon, Nov 11, 2019 at 9:10 AM Christian Borntraeger
> <borntraeger@xxxxxxxxxx> wrote:
> > On 08.11.19 20:57, Arnd Bergmann wrote:
> > > On Fri, Nov 8, 2019 at 6:01 PM Will Deacon <will@xxxxxxxxxx> wrote:
> > >>
> > >> In preparation for allowing architectures to define their own
> > >> implementation of the 'READ_ONCE()' macro, move the generic
> > >> '{READ,WRITE}_ONCE()' definitions out of the unwieldy 'linux/compiler.h'
> > >> and into a new 'rwonce.h' header under 'asm-generic'.
> > >
> > > Adding Christian Bornträger to Cc, he originally added the
> > > READ_ONCE()/WRITE_ONCE()
> > > code.
> > >
> > > I wonder if it would be appropriate now to revert back to a much simpler version
> > > of these helpers for any modern compiler. As I understand, only gcc-4.6 and
> > > gcc4.7 actually need the song-and-dance version with the union and switch/case,
> > > while for others, we can might be able back to a macro doing a volatile access.
> >
> > As far as I know this particular issue with volatile access on aggregate types
> > was fixed in gcc 4.8. On the other hand we know that the current construct will
> > work on all compilers. Not so sure about the orignal ACCESS_ONCE implementation.
>
> I've seen problems with clang on the current version, leading to unnecessary
> temporaries being spilled to the stack in some cases, so I think it would still
> help to simplify it.
>
> We probably don't want the exact ACCESS_ONCE() implementation back
> that existed before, but rather something that implements the stricter
> READ_ONCE() and WRITE_ONCE(). I'd probably also want to avoid the
> __builtin_memcpy() exception for odd-sized accesses and instead have
> a separate way to do those.
If you have a patch, I'm happy to carry it at the end of the series to
avoid conflicts. It's not completely clear to me what you're after, so if
you need me to adjust anything here then please shout!
Will
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
