public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	torvalds@linux-foundation.org
Subject: Re: [PATCH 9/9] kernel: tighten rules for ACCESS ONCE
Date: Thu, 4 Dec 2014 06:41:45 -0800	[thread overview]
Message-ID: <20141204144145.GO25340@linux.vnet.ibm.com> (raw)
In-Reply-To: <54802939.8010701@de.ibm.com>

On Thu, Dec 04, 2014 at 10:28:25AM +0100, Christian Borntraeger wrote:
> Am 04.12.2014 um 01:16 schrieb Paul E. McKenney:
> >>   * merging, or refetching absolutely anything at any time.  Its main intended
> >> >   * use is to mediate communication between process-level code and irq/NMI
> >> >   * handlers, all running on the same CPU.
> > This comment is obsolete in the same way as that of READ_ONCE() and
> > ASSIGN_ONCE(), but probably more to the point to just get rid of
> > ACCESS_ONCE().  ;-)
> > 
> >> > 
> 
> Its now 
> 
> /*
>  * Prevent the compiler from merging or refetching accesses.  The compiler
>  * is also forbidden from reordering successive instances of ACCESS_ONCE(),
>  * but only when the compiler is aware of some particular ordering.  One way
>  * to make the compiler aware of ordering is to put the two invocations of
>  * ACCESS_ONCE() in different C statements.
>  *
>  * ACCESS_ONCE will only work on scalar types. For union types, ACCESS_ONCE
>  * on a union member will work as long as the size of the member matches the
>  * size of the union and the size is smaller than word size.
>  *
>  * The major use cases of ACCESS_ONCE used to be (1) Mediating communication
>  * between process-level code and irq/NMI handlers, all running on the same CPU,
>  * and (2) Ensuring that the compiler does not  fold, spindle, or otherwise
>  * mutilate accesses that either do not require ordering or that interact
>  * with an explicit memory barrier or atomic instruction that provides the
>  * required ordering.
>  *
>  * If possible use READ_ONCE/ASSIGN_ONCE instead.
>  */

Looks good!

							Thanx, Paul


  reply	other threads:[~2014-12-04 14:42 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-03 22:30 [PATCHv4 0/9] ACCESS_ONCE and non-scalar accesses Christian Borntraeger
2014-12-03 22:30 ` [PATCH 1/9] kernel: Provide READ_ONCE and ASSIGN_ONCE Christian Borntraeger
2014-12-04  0:07   ` Paul E. McKenney
2014-12-04  9:24     ` Christian Borntraeger
2014-12-04 14:41       ` Paul E. McKenney
2014-12-03 22:30 ` [PATCH 2/9] mm: replace ACCESS_ONCE with READ_ONCE or barriers Christian Borntraeger
2014-12-04  0:09   ` Paul E. McKenney
2014-12-03 22:30 ` [PATCH 3/9] x86/spinlock: Replace ACCESS_ONCE with READ_ONCE Christian Borntraeger
2014-12-04  0:10   ` Paul E. McKenney
2014-12-03 22:30 ` [PATCH 4/9] x86/gup: " Christian Borntraeger
2014-12-04  0:10   ` Paul E. McKenney
2014-12-03 22:30 ` [PATCH 5/9] mips/gup: " Christian Borntraeger
2014-12-04  0:11   ` Paul E. McKenney
2014-12-03 22:30 ` [PATCH 6/9] arm64/spinlock: Replace ACCESS_ONCE READ_ONCE Christian Borntraeger
2014-12-04  0:11   ` Paul E. McKenney
2014-12-03 22:30 ` [PATCH 7/9] arm/spinlock: Replace ACCESS_ONCE with READ_ONCE Christian Borntraeger
2014-12-04  0:12   ` Paul E. McKenney
2014-12-03 22:30 ` [PATCH 8/9] s390/kvm: REPLACE " Christian Borntraeger
2014-12-04  0:12   ` Paul E. McKenney
2014-12-03 22:30 ` [PATCH 9/9] kernel: tighten rules for ACCESS ONCE Christian Borntraeger
2014-12-04  0:16   ` Paul E. McKenney
2014-12-04  9:28     ` Christian Borntraeger
2014-12-04 14:41       ` Paul E. McKenney [this message]
2014-12-04 15:24 ` [PATCHv4 0/9] ACCESS_ONCE and non-scalar accesses Christian Borntraeger
2014-12-04 23:40 ` Linus Torvalds

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=20141204144145.GO25340@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@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