From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965142AbcDMH2y (ORCPT ); Wed, 13 Apr 2016 03:28:54 -0400 Received: from terminus.zytor.com ([198.137.202.10]:51276 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759173AbcDMH2w (ORCPT ); Wed, 13 Apr 2016 03:28:52 -0400 Date: Wed, 13 Apr 2016 00:28:12 -0700 From: tip-bot for SeongJae Park Message-ID: Cc: sj38.park@gmail.com, hpa@zytor.com, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, tglx@linutronix.de, peterz@infradead.org, paulmck@linux.vnet.ibm.com, mingo@kernel.org, dhowells@redhat.com, torvalds@linux-foundation.org Reply-To: torvalds@linux-foundation.org, dhowells@redhat.com, mingo@kernel.org, paulmck@linux.vnet.ibm.com, peterz@infradead.org, tglx@linutronix.de, akpm@linux-foundation.org, hpa@zytor.com, linux-kernel@vger.kernel.org, sj38.park@gmail.com In-Reply-To: <1460476375-27803-2-git-send-email-paulmck@linux.vnet.ibm.com> References: <1460476375-27803-2-git-send-email-paulmck@linux.vnet.ibm.com> To: linux-tip-commits@vger.kernel.org Subject: [tip:locking/core] locking/Documentation: Fix missed s/lock/acquire renames Git-Commit-ID: 166bda7122c8e817f039bf738cf05ab3b7278732 X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: 166bda7122c8e817f039bf738cf05ab3b7278732 Gitweb: http://git.kernel.org/tip/166bda7122c8e817f039bf738cf05ab3b7278732 Author: SeongJae Park AuthorDate: Tue, 12 Apr 2016 08:52:50 -0700 Committer: Ingo Molnar CommitDate: Wed, 13 Apr 2016 08:52:21 +0200 locking/Documentation: Fix missed s/lock/acquire renames The terms 'lock'/'unlock' were changed to 'acquire'/'release' by the following commit: 2e4f5382d12a4 ("locking/doc: Rename LOCK/UNLOCK to ACQUIRE/RELEASE") However, the commit missed to change the table of contents - fix that. Also, the dumb rename changed the section name 'Locking functions' to an actively misleading 'Acquiring functions' section name. Rename it to 'Lock acquisition functions' instead. Suggested-by: David Howells Signed-off-by: SeongJae Park Signed-off-by: Paul E. McKenney Cc: Andrew Morton Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: bobby.prani@gmail.com Cc: dipankar@in.ibm.com Cc: dvhart@linux.intel.com Cc: edumazet@google.com Cc: fweisbec@gmail.com Cc: jiangshanlai@gmail.com Cc: josh@joshtriplett.org Cc: mathieu.desnoyers@efficios.com Cc: oleg@redhat.com Cc: rostedt@goodmis.org Link: http://lkml.kernel.org/r/1460476375-27803-2-git-send-email-paulmck@linux.vnet.ibm.com [ Rewrote the changelog. ] Signed-off-by: Ingo Molnar --- Documentation/memory-barriers.txt | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index ec12890..38b1ce1 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -31,15 +31,15 @@ Contents: (*) Implicit kernel memory barriers. - - Locking functions. + - Lock acquisition functions. - Interrupt disabling functions. - Sleep and wake-up functions. - Miscellaneous functions. - (*) Inter-CPU locking barrier effects. + (*) Inter-CPU acquiring barrier effects. - - Locks vs memory accesses. - - Locks vs I/O accesses. + - Acquires vs memory accesses. + - Acquires vs I/O accesses. (*) Where are memory barriers needed? @@ -1859,7 +1859,7 @@ This is a variation on the mandatory write barrier that causes writes to weakly ordered I/O regions to be partially ordered. Its effects may go beyond the CPU->Hardware interface and actually affect the hardware at some level. -See the subsection "Locks vs I/O accesses" for more information. +See the subsection "Acquires vs I/O accesses" for more information. =============================== @@ -1874,8 +1874,8 @@ provide more substantial guarantees, but these may not be relied upon outside of arch specific code. -ACQUIRING FUNCTIONS -------------------- +LOCK ACQUISITION FUNCTIONS +-------------------------- The Linux kernel has a number of locking constructs: