All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-kernel@vger.kernel.org, Davidlohr Bueso <dave@stgolabs.net>,
	Peter Zijlstra <peterz@infradead.org>,
	Will Deacon <will.deacon@arm.com>,
	akpm@linux-foundation.org, benh@kernel.crashing.org,
	bp@alien8.de, davem@davemloft.net, fw@strlen.de,
	jiangshanlai@gmail.com, johannes.berg@intel.com,
	jonathanh@nvidia.com, kadlec@blackhole.kfki.hu,
	mchehab@kernel.org, mpe@ellerman.id.au, pablo@netfilter.org,
	paulus@samba.org, petr@vandrovec.name,
	sakari.ailus@linux.intel.com, shuah@kernel.org,
	snitzer@redhat.com, thierry.reding@gmail.com,
	thor.thayer@linux.intel.com, tj@kernel.org,
	viro@zeniv.linux.org.uk
Subject: Re: [PATCH 00/13] Preparatory work to kill off ACCESS_ONCE()
Date: Mon, 9 Oct 2017 13:02:23 -0700	[thread overview]
Message-ID: <20171009200223.GA27372@linux.vnet.ibm.com> (raw)
In-Reply-To: <1507573730-8083-1-git-send-email-mark.rutland@arm.com>

On Mon, Oct 09, 2017 at 07:28:37PM +0100, Mark Rutland wrote:
> Hi all,
> 
> There's a general want to kill off ACCESS_ONCE(), which is required to kill off
> smp_read_barrier_depends(), and to support debug features which require
> instrumenting reads and writes separately.
> 
> Thanks to preparatory work by a number of people, it's largely possible to
> script this with the Coccinelle patch below. However, this breaks a handful of
> cases, and renders some comments stale.
> 
> This series fixes up said cases, and comments. Where fixups have been made,
> I've converted the entire file for consistency. The remaining code can be
> converted by Coccinelle script, allowing for the subsequent removal of
> ACCESS_ONCE().
> 
> I've pushed this series, complete with an example treewide conversion of
> v4.14-rc4 to my core/access-once branch [1,2].

And this all that is left, aside from definitions and comments associated
with those definitions.  Cool!

Feel free to pull this into your preparation series.

							Thanx, Paul

------------------------------------------------------------------------

commit ed940234966f4857e23dd5f16aa8f200fc85dac6
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Mon Oct 9 12:59:18 2017 -0700

    treewide: Kill off remaining ACCESS_ONCE()
    
    This commit removes instances of ACCESS_ONCE() not located by Mark Rutland's
    coccinelle script, for example, those in complex macro definitions and
    those in comments.  Removing ACCESS_ONCE() in favor of READ_ONCE() and
    WRITE_ONCE() provides tools such as KTSAN the read/write distinction that
    they need to better detect concurrency bugs.  In addition, removing
    ACCESS_ONCE() is one necessary step towards removing special cases for
    DEC Alpha from the Linux-kernel memory model.
    
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

diff --git a/Documentation/filesystems/path-lookup.md b/Documentation/filesystems/path-lookup.md
index 1b39e084a2b2..50ea32a51626 100644
--- a/Documentation/filesystems/path-lookup.md
+++ b/Documentation/filesystems/path-lookup.md
@@ -826,9 +826,9 @@ If the filesystem may need to revalidate dcache entries, then
 *is* passed the dentry but does not have access to the `inode` or the
 `seq` number from the `nameidata`, so it needs to be extra careful
 when accessing fields in the dentry.  This "extra care" typically
-involves using `ACCESS_ONCE()` or the newer [`READ_ONCE()`] to access
-fields, and verifying the result is not NULL before using it.  This
-pattern can be see in `nfs_lookup_revalidate()`.
+involves using [`READ_ONCE()`] to access fields, and verifying the
+result is not NULL before using it.  This pattern can be see in
+`nfs_lookup_revalidate()`.
 
 A pair of patterns
 ------------------
diff --git a/mm/memory.c b/mm/memory.c
index a728bed16c20..cae514e7dcfc 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3891,9 +3891,9 @@ static int handle_pte_fault(struct vm_fault *vmf)
 		/*
 		 * some architectures can have larger ptes than wordsize,
 		 * e.g.ppc44x-defconfig has CONFIG_PTE_64BIT=y and
-		 * CONFIG_32BIT=y, so READ_ONCE or ACCESS_ONCE cannot guarantee
-		 * atomic accesses.  The code below just needs a consistent
-		 * view for the ifs and we later double check anyway with the
+		 * CONFIG_32BIT=y, so READ_ONCE cannot guarantee atomic
+		 * accesses.  The code below just needs a consistent view
+		 * for the ifs and we later double check anyway with the
 		 * ptl lock held. So here a barrier will do.
 		 */
 		barrier();

      parent reply	other threads:[~2017-10-09 20:02 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-09 18:28 [PATCH 00/13] Preparatory work to kill off ACCESS_ONCE() Mark Rutland
2017-10-09 18:28 ` [PATCH 01/13] dm integrity: " Mark Rutland
2017-10-09 18:28 ` [PATCH 02/13] EDAC, altera: " Mark Rutland
2017-10-09 23:12   ` Thor Thayer
2017-10-10  9:30     ` Mark Rutland
2017-10-09 18:28 ` [PATCH 03/13] firmware/ivc: " Mark Rutland
2017-10-09 18:28 ` [PATCH 04/13] fs: dcache: " Mark Rutland
2017-10-09 18:28 ` [PATCH 05/13] fs: ncpfs: " Mark Rutland
2017-10-09 18:28 ` [PATCH 06/13] media: dvb_ringbuffer: " Mark Rutland
2017-10-09 18:28 ` [PATCH 07/13] net: netlink/netfilter: " Mark Rutland
2017-10-09 18:28 ` [PATCH 08/13] net/ipv4/tcp_input.c: " Mark Rutland
2017-10-09 19:03   ` Mark Rutland
2017-10-09 18:28 ` [PATCH 09/13] net: average: " Mark Rutland
2017-10-10  9:28   ` Mark Rutland
2017-10-09 18:28 ` [PATCH 10/13] samples: mic/mpssd/mpssd.c: " Mark Rutland
2017-10-09 18:28 ` [PATCH 11/13] selftests/powerpc: " Mark Rutland
2017-10-10  0:45   ` Michael Ellerman
2017-10-10  9:32     ` Mark Rutland
2017-10-09 18:28 ` [PATCH 12/13] workqueue: " Mark Rutland
2017-10-10 14:06   ` Tejun Heo
2017-10-10 16:21     ` Mark Rutland
2017-10-09 18:28 ` [PATCH 13/13] rcutorture: formal: prepare for ACCESS_ONCE() removal Mark Rutland
2017-10-09 19:51   ` Paul E. McKenney
2017-10-10  9:54     ` Mark Rutland
2017-10-10 12:47       ` Paul E. McKenney
2017-10-10 12:50         ` Mark Rutland
2017-10-10 14:52           ` Paul E. McKenney
2017-10-10 16:24             ` Mark Rutland
2017-10-10 16:35               ` Paul E. McKenney
2017-10-10 16:27             ` Joe Perches
2017-10-10 16:35               ` Paul E. McKenney
2017-10-10 16:41               ` Mark Rutland
2017-10-10 16:57                 ` [Ksummit-discuss] " Joe Perches
2017-10-10 16:57                   ` Joe Perches
2017-10-10 17:06                   ` [Ksummit-discuss] " Mark Rutland
2017-10-10 17:06                     ` Mark Rutland
2017-10-09 20:02 ` Paul E. McKenney [this message]

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=20171009200223.GA27372@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=bp@alien8.de \
    --cc=dave@stgolabs.net \
    --cc=davem@davemloft.net \
    --cc=fw@strlen.de \
    --cc=jiangshanlai@gmail.com \
    --cc=johannes.berg@intel.com \
    --cc=jonathanh@nvidia.com \
    --cc=kadlec@blackhole.kfki.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mchehab@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=pablo@netfilter.org \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=petr@vandrovec.name \
    --cc=sakari.ailus@linux.intel.com \
    --cc=shuah@kernel.org \
    --cc=snitzer@redhat.com \
    --cc=thierry.reding@gmail.com \
    --cc=thor.thayer@linux.intel.com \
    --cc=tj@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will.deacon@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.