linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Yunjae Lee <lyj7694@gmail.com>,
	SeongJae Park <sj38.park@gmail.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Matt Turner <mattst88@gmail.com>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Richard Henderson <rth@twiddle.net>,
	Peter Zijlstra <peterz@infradead.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Michael Ellerman <mpe@ellerman.id.au>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>, Joe Perches <joe@perches.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	alpha <linux-alpha@vger.kernel.org>,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH 01/13] compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h
Date: Tue, 12 Nov 2019 11:36:47 +0000	[thread overview]
Message-ID: <20191112113646.GC17835@willie-the-truck> (raw)
In-Reply-To: <CAK8P3a21KdGKMDDPs3jc9XEg3=LbzFnGwVm+xDTB+EqGXiZorA@mail.gmail.com>

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@de.ibm.com> wrote:
> > On 08.11.19 20:57, Arnd Bergmann wrote:
> > > On Fri, Nov 8, 2019 at 6:01 PM Will Deacon <will@kernel.org> 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

  reply	other threads:[~2019-11-12 11:36 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-08 17:01 [PATCH 00/13] Finish off [smp_]read_barrier_depends() Will Deacon
2019-11-08 17:01 ` [PATCH 01/13] compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h Will Deacon
2019-11-08 19:57   ` Arnd Bergmann
2019-11-11  8:10     ` Christian Borntraeger
2019-11-11  9:32       ` Arnd Bergmann
2019-11-12 11:36         ` Will Deacon [this message]
2019-11-08 17:01 ` [PATCH 02/13] READ_ONCE: Undefine internal __READ_ONCE_SIZE macro after use Will Deacon
2019-11-08 17:01 ` [PATCH 03/13] READ_ONCE: Allow __READ_ONCE_SIZE cases to be overridden by the architecture Will Deacon
2019-11-08 17:01 ` [PATCH 04/13] vhost: Remove redundant use of read_barrier_depends() barrier Will Deacon
2019-11-08 17:01 ` [PATCH 05/13] alpha: Override READ_ONCE() with barriered implementation Will Deacon
2019-11-08 17:01 ` [PATCH 06/13] READ_ONCE: Remove smp_read_barrier_depends() invocation Will Deacon
2019-11-08 17:01 ` [PATCH 07/13] alpha: Replace smp_read_barrier_depends() usage with smp_[r]mb() Will Deacon
2019-11-08 17:01 ` [PATCH 08/13] locking/barriers: Remove definitions for [smp_]read_barrier_depends() Will Deacon
2019-11-08 17:01 ` [PATCH 09/13] Documentation/barriers: Remove references to [smp_]read_barrier_depends() Will Deacon
2019-11-21 19:32   ` [PATCH] Documentation/barriers/kokr: " SeongJae Park
2019-11-26 22:20     ` Paul E. McKenney
2019-11-29 18:08     ` [PATCH v2] " SeongJae Park
2019-12-06 17:20       ` SeongJae Park
2019-12-06 20:44         ` Paul E. McKenney
2019-12-06 21:29           ` SeongJae Park
2019-12-06 22:08             ` Paul E. McKenney
2019-12-06 22:38               ` SeongJae Park
2019-12-06 22:51                 ` Paul E. McKenney
2019-12-09  9:44                   ` Will Deacon
2019-12-09 17:00                     ` Paul E. McKenney
2019-12-09 17:06                       ` Will Deacon
2019-12-09 17:43                         ` SeongJae Park
2019-11-08 17:01 ` [PATCH 10/13] tools/memory-model: Remove smp_read_barrier_depends() from informal doc Will Deacon
2019-11-08 17:42   ` Alan Stern
2019-11-08 17:01 ` [PATCH 11/13] powerpc: Remove comment about read_barrier_depends() Will Deacon
2019-11-20 10:37   ` Michael Ellerman
2019-11-26 22:24     ` Paul E. McKenney
2019-11-08 17:01 ` [PATCH 12/13] include/linux: Remove smp_read_barrier_depends() from comments Will Deacon
2019-11-08 17:01 ` [PATCH 13/13] checkpatch: Remove checks relating to [smp_]read_barrier_depends() Will Deacon
2019-11-08 18:50 ` [PATCH 00/13] Finish off [smp_]read_barrier_depends() Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191112113646.GC17835@willie-the-truck \
    --to=will@kernel.org \
    --cc=arnd@arndb.de \
    --cc=boqun.feng@gmail.com \
    --cc=borntraeger@de.ibm.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jasowang@redhat.com \
    --cc=joe@perches.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lyj7694@gmail.com \
    --cc=mattst88@gmail.com \
    --cc=mpe@ellerman.id.au \
    --cc=mst@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rth@twiddle.net \
    --cc=sj38.park@gmail.com \
    --cc=stern@rowland.harvard.edu \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).