Received: by 10.223.185.116 with SMTP id b49csp1854229wrg; Thu, 22 Feb 2018 04:21:07 -0800 (PST) X-Google-Smtp-Source: AH8x224Qfut1eg4dYMcMK6iOowbskMC0UwKFhdbogotjWpal0XCLnzbwZMWtLnwGJK5ZxHqPRNKL X-Received: by 2002:a17:902:328:: with SMTP id 37-v6mr6529687pld.398.1519302067222; Thu, 22 Feb 2018 04:21:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519302067; cv=none; d=google.com; s=arc-20160816; b=qVDGZgL0R0SABOVcwFnS171y2YU0kHFaJE8unb/zFzDVA3mv9qiED2GmlMVr331YOm hcNONv0RVt/06Yopzxg4qb1QsGNSUS82h9XwT9zs3RIOfjtBrHeRJgYZwzHOYzWV4vB3 tKlCrQAvH6JdG45sz0gEQq7YdP7HP4M0K02UYvNTma6VDjIaJ7ZXcRVS1W0DOBhD6OcW 8fjHr8/oqtbBA8A20ItHay13FivVFLxCp5pP2w+biT8JfpWE8Zu14nhz1i2LLZgjzAiv sTl3RX3RA4/MotwjwZBukshD61jfKvUqb/SwHBrKh8Op5gDHouu1qgIcnWLSkMZzzUE2 GoOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=blWl9p2f841+T03muZNqW1tfqlac5bWPdMIp+hzK8pM=; b=CZnZJFCyRuuqgoDfTzEYyvIy6hgAAbK/DF0bcnJ1yUhCQA5LCY2Jm3l0GM1xqhRsvR 6NYOwGh7S9o+QC6R055BK8/IFGm3M0UObyPrKgUAlQVt0WAfnVQEoTxjv1F4QZneOHTS rD9MbbtDKzNmTOMqlQt4nCBRsOOCm4AhKa1odPwI3kAQNmPTRWrb4jPflPDbHMfmPbJj FFor2phXW1/p/INEH5kq+kPc0ED5CsqfRFMRA6/fenp8OUV1kyU8g+S2yuMFJrlfDx0K /Vi0wyKnl4VzdTzmDaOV7ySzTFOry+ZzFPZfIPtsA2Wr5sweBmUDrcjvCf9QYoHw0GH5 OogA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=A+CkDyhP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c13si5234394pgn.696.2018.02.22.04.20.51; Thu, 22 Feb 2018 04:21:07 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=A+CkDyhP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753750AbeBVMUC (ORCPT + 99 others); Thu, 22 Feb 2018 07:20:02 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:55890 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753719AbeBVMUA (ORCPT ); Thu, 22 Feb 2018 07:20:00 -0500 Received: by mail-wm0-f66.google.com with SMTP id q83so3550209wme.5 for ; Thu, 22 Feb 2018 04:20:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=blWl9p2f841+T03muZNqW1tfqlac5bWPdMIp+hzK8pM=; b=A+CkDyhPfhkGSAME3jzKIEKE3ZpqhscSBdzNVR9VOKnC/OYY78Kt88Us1quazXXW2e qn58EmzmRiEaK+b8p78qA5PEzFur6KR6OUtrOHSrki0irLeCI/o0trTrZwNwnQaqZViH Xye0Ekm2ns8cCI5Bjkbdm3izhZgY+r8wTvz1c32bDjKU/AClHw75tJ4rIfhxz8bjwVue UEbLexK3Pwl5ml/FT0NoLBCevM1F5IE9tGWilDZg3Fd1OybZHbHU9yolEH+1p+coYl4/ pxN1GLw/ND60Yq7jukuqS+B5Cbkvr2yiTt+3gTn3Klf1VT/0dzqpshLckXz8JOdEIeT7 ZzIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=blWl9p2f841+T03muZNqW1tfqlac5bWPdMIp+hzK8pM=; b=KNG6upofk+ZXDvN6wGRTdPaONm4aGG1G46HV/WSZlQ9Rm7l4NIlB3Sp4Whi930jWwV QUyDmZiO1BjcGX7jp00bL44LisENlj0L40SQNOVorS+xP7F/vv2vTkptm7aeKPYVg9Hx rgQXsnxZBARFC6htMaRmqH7PcpK1O2pqjT7fGEXXTfD2uqm7WXuUHOkmNHV4vCDDUuMt ar7ts9XaFQdmhdqfDrNF0YnD6VwAOHgoWzgvNpMTyyiFrfRfel8WA+XO3xx4FVEkr050 O/t0Vk1kftG2mfnOaEK32QIdI1ugYCu0VzcdK94PgsKaxJLHMcOz7mcRsy+87EfPL9WQ YkcA== X-Gm-Message-State: APf1xPBuELS3wwn7hen62kynCxgeOztJTSWAOUMxU2xwIUYLYmEXAIgr Uv9Hj7BWGJddeLRFs75OhH793dWC X-Received: by 10.80.128.230 with SMTP id 93mr9331375edb.34.1519301999065; Thu, 22 Feb 2018 04:19:59 -0800 (PST) Received: from andrea.amarulasolutions.com (85.100.broadband17.iol.cz. [109.80.100.85]) by smtp.gmail.com with ESMTPSA id o47sm201851edc.10.2018.02.22.04.19.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 22 Feb 2018 04:19:58 -0800 (PST) From: Andrea Parri To: linux-kernel@vger.kernel.org Cc: Andrea Parri , Palmer Dabbelt , Albert Ou , Daniel Lustig , Alan Stern , Will Deacon , Peter Zijlstra , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Ingo Molnar , Linus Torvalds , linux-riscv@lists.infradead.org Subject: [RFC PATCH] riscv/locking: Strengthen spin_lock() and spin_unlock() Date: Thu, 22 Feb 2018 13:19:50 +0100 Message-Id: <1519301990-11766-1-git-send-email-parri.andrea@gmail.com> X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The LKMM defines certain memory ordering constraints for spin_lock(), spin_unlock() and other primitives that the kernel developer can rely on; unfortunately, some of these constraints are not currently met by the RISC-V implementation of spin_lock(), spin_unlock(). The following MP-like program exemplifies the issue: according to our LKMM, program "unlock-lock-read-ordering" below can never reach state (1:r0=1 /\ 1:r1=0). However, when we map this C program to the RISCV program "RISCV-unlock-lock-read-ordering" below following the current implementation, the corresponding state is reachable according to the RISCV specification and its formalizations [2]. C unlock-lock-read-ordering {} /* s initially owned by P1 */ P0(int *x, int *y) { WRITE_ONCE(*x, 1); smp_wmb(); WRITE_ONCE(*y, 1); } P1(int *x, int *y, spinlock_t *s) { int r0; int r1; r0 = READ_ONCE(*y); spin_unlock(s); spin_lock(s); r1 = READ_ONCE(*y); } exists (1:r0=1 /\ 1:r1=0) RISCV RISCV-unlock-lock-read-ordering { 0:x2=x; 0:x4=y; 1:x2=y; 1:x4=x; 1:x6=s; s=1; } P0 | P1 ; ori x1,x0,1 | lw x1,0(x2) ; sw x1,0(x2) | amoswap.w.rl x0,x0,(x6) ; fence w,w | ori x5,x0,1 ; ori x3,x0,1 | amoswap.w.aq x0,x5,(x6) ; sw x3,0(x4) | lw x3,0(x4) ; exists (1:x1=1 /\ 1:x3=0) The issue can in fact be exarcebated if, as envisaged/discussed in [3], the LKMM will be modified to become even more "demanding" on the order- ing constraints associated to the locking primitives. For example the state (1:r0=1 /\ 1:r1=0) in program "unlock-lock-write-ordering" below is currently allowed by LKMM (as is the corresponding state in "RISCV- unlock-lock-write-ordering" below). However, proposals modifying LKMM to _forbid_ that state have already appeared on LKML [4]. C unlock-lock-write-ordering {} /* s initially owned by P0 */ P0(int *x, int *y, spinlock_t *s) { WRITE_ONCE(*x, 1); spin_unlock(s); spin_lock(s); WRITE_ONCE(*y, 1); } P1(int *x, int *y) { int r0; int r1; r0 = READ_ONCE(*y); smp_rmb(); r1 = READ_ONCE(*y); } exists (1:r0=1 /\ 1:r1=0) RISCV RISCV-unlock-lock-write-ordering { 0:x2=x; 0:x4=y; 0:x6=s; 1:x2=y; 1:x4=x; s=1; } P0 | P1 ; ori x1,x0,1 | lw x1,0(x2) ; sw x1,0(x2) | fence r,r ; amoswap.w.rl x0,x0,(x6) | lw x3,0(x4) ; ori x5,x0,1 | ; amoswap.w.aq x0,x5,(x6) | ; ori x3,x0,1 | ; sw x3,0(x4) | ; exists (1:x1=1 /\ 1:x3=0) [Curiously, RISC-V's current implementations of smp_load_acquire() and smp_store_release() provide way stronger ordering than what currently required by LKMM since those're relying on the generic implementation (c.f, also, [5]). ] This RFC fixes the issue by strengthening RISC-V's implementations of spin_lock() and spin_unlock(), based on "A spinlock with fences" from Section 2.3.5 ("Acquire/Release Ordering") of the RISC-V draft spec. It does _not_ attempt to fix read-lock and atomics (for which, AFAICT, similar considerations would hold). IMPORTANT. This patch is _NOT_ intended to be applied as is. Rather, this is intended to test the waters, implicit questions being "Should we take this direction?" "Are changes to LKMM needed?" (and develop a technical discussion on the above issues.) [1] https://marc.info/?l=linux-kernel&m=151633436614259&w=2 [2] https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/hKywNHBkAXM [3] https://marc.info/?l=linux-kernel&m=151181741400461&w=2 [4] https://marc.info/?l=linux-kernel&m=151871035014425&w=2 [5] https://marc.info/?l=linux-kernel&m=151912186913692&w=2 Signed-off-by: Andrea Parri Cc: Palmer Dabbelt Cc: Albert Ou Cc: Daniel Lustig Cc: Alan Stern Cc: Will Deacon Cc: Peter Zijlstra Cc: Boqun Feng Cc: Nicholas Piggin Cc: David Howells Cc: Jade Alglave Cc: Luc Maranget Cc: "Paul E. McKenney" Cc: Akira Yokosawa Cc: Ingo Molnar Cc: Linus Torvalds Cc: linux-riscv@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- arch/riscv/include/asm/spinlock.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/riscv/include/asm/spinlock.h b/arch/riscv/include/asm/spinlock.h index 2fd27e8ef1fd6..2f89fc62c9196 100644 --- a/arch/riscv/include/asm/spinlock.h +++ b/arch/riscv/include/asm/spinlock.h @@ -28,8 +28,9 @@ static inline void arch_spin_unlock(arch_spinlock_t *lock) { + RISCV_FENCE(rw,w); __asm__ __volatile__ ( - "amoswap.w.rl x0, x0, %0" + "amoswap.w x0, x0, %0" : "=A" (lock->lock) :: "memory"); } @@ -39,10 +40,11 @@ static inline int arch_spin_trylock(arch_spinlock_t *lock) int tmp = 1, busy; __asm__ __volatile__ ( - "amoswap.w.aq %0, %2, %1" + "amoswap.w %0, %2, %1" : "=r" (busy), "+A" (lock->lock) : "r" (tmp) : "memory"); + RISCV_FENCE(r,rw); return !busy; } -- 2.7.4