From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934688AbcHaNmq (ORCPT ); Wed, 31 Aug 2016 09:42:46 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:34083 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933073AbcHaNmn (ORCPT ); Wed, 31 Aug 2016 09:42:43 -0400 From: Manfred Spraul To: benh@kernel.crashing.org, paulmck@linux.vnet.ibm.com, Ingo Molnar , Boqun Feng , Peter Zijlstra , Andrew Morton Cc: LKML , 1vier1@web.de, Davidlohr Bueso , Manfred Spraul Subject: [PATCH 2/5] spinlock: Document memory barrier rules for spin_lock and spin_unlock(). Date: Wed, 31 Aug 2016 15:42:27 +0200 Message-Id: <1472650950-3131-3-git-send-email-manfred@colorfullife.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1472650950-3131-1-git-send-email-manfred@colorfullife.com> References: <1472650950-3131-1-git-send-email-manfred@colorfullife.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In theory, the memory ordering rules for spinlock() and spin_unlock() are simple: spin_lock is ACQUIRE, spin_unlock is RELEASE. What is missing is a clear documentation for the corner cases: - What is covered by the ACQUIRE during spin_lock: only the lock load or also the lock store? - spin_unlock_wait() is an ACQUIRE. - No memory ordering is enforced by spin_is_locked(). The patch adds this into Documentation/locking/spinlock.txt. Signed-off-by: Manfred Spraul --- Documentation/locking/spinlocks.txt | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/Documentation/locking/spinlocks.txt b/Documentation/locking/spinlocks.txt index ff35e40..0696d68 100644 --- a/Documentation/locking/spinlocks.txt +++ b/Documentation/locking/spinlocks.txt @@ -40,6 +40,15 @@ example, internal driver data structures that nobody else ever touches). touches a shared variable has to agree about the spinlock they want to use. + NOTE! Code that needs stricter memory barriers than ACQUIRE during + LOCK and RELEASE during UNLOCK must use appropriate memory barriers + such as smp_mb__before_spinlock(). Especially, the ACQUIRE during + LOCK applies to reading the lock state. Operations within the + guarded area can happen before the lock store. + spin_unlock_wait() has ACQUIRE semantics. + spin_is_locked() is not a memory barrier, callers that use it for + locking must add appropriate barriers. + ---- Lesson 2: reader-writer spinlocks. -- 2.7.4