From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934585AbcHaNmn (ORCPT ); Wed, 31 Aug 2016 09:42:43 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:35102 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933073AbcHaNml (ORCPT ); Wed, 31 Aug 2016 09:42:41 -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 0/5 V5] Clarify/standardize memory barriers for lock/unlock Date: Wed, 31 Aug 2016 15:42:25 +0200 Message-Id: <1472650950-3131-1-git-send-email-manfred@colorfullife.com> X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, V5: Major restructuring based on input from Peter and Davidlohr. As discussed before: If a high-scalability locking scheme is built with multiple spinlocks, then often additional memory barriers are required. The documentation was not as clear as possible, and memory barriers were missing / superfluous in the implementation. Patch 1: sem.c: Remove the smp_rmb() after spin_unlock_wait(). Patch 2: Documentation Patch 3: Add spinlock_store_acquire(), update ipc/sem.c Patch 4: Move smp_mb__after_unlock_lock to Patch 5: Fix memory ordering for nf_conntrack The patches are safe for all architectures, the default is smp_mb(). Patch 5 is larger than required, it rewrites the conntrack logic with the code from ipc/sem.c. I think the new code is simpler and more realtime-friendly. @Peter: A hint if qspinlocks can omit the smp_mb() would be appreciated (everywhere or x86-only). The comments on top of queued_spin_unlock_wait() had convinced me that no additional barrier is required. But the comment also convinced me that on x86, no further barrier would be required for a full smp_mb() - and there you wrote that this is wrong. @Andrew: The patches are relative to mmots. Could you include them in your tree, with the target of including in linux-next? -- Manfred