Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3243627imu; Fri, 18 Jan 2019 07:12:58 -0800 (PST) X-Google-Smtp-Source: ALg8bN6hHo+aWjwGy2FDB5zm6rDa87kZ1o8mdRFqohv8IkcQty3uuTgjLCHzWJxOhJFo1eOVpLT3 X-Received: by 2002:a17:902:7848:: with SMTP id e8mr19956853pln.100.1547824378593; Fri, 18 Jan 2019 07:12:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547824378; cv=none; d=google.com; s=arc-20160816; b=dF+godg5SWkCqhJGxcOZ7h7XuvUiYK2cfno51Om9reQadXFnuQSlIg8GwFI0LfYC3f 8dNFs3sgbLhTESEQ5JS9o7Lkbv1DoyjWuY0xMC0pXDIbJKjjS8ts5ds5G8WdW3f5fZno Tx9kCpmP9a1yxbp+45jM5Sh1hnbjcrAcLd3IMYCTxgUYK0SklfFdFa5L8waeWgDkYD9r vXyBVCFYZ99OIWToe0U4rdcdLuuqLRbpZAwZ1t2ZhR8KCCI1YKd9sYeMo6CLhZxUeYSw 3vM2TkyKc7oz5i0yYfrsmnVBYiRN1A+uKj1r62G4gxDzhvSpDZjf0V20W3s/fOUgk1n9 B4kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=kxQ89StJmsTqIiEZtG/XpTqpLvHWhu+atzTOb118wRY=; b=q+zBW3UrrEm5lf7n2rHibbTzEl9g140G5aYV6Q11BrHOCtLVjbBNHTF0nhZ3Sla/Hs 6+XKzZiNzUmeSdSmPR1uxAF2GnM+wt4s9DcGYc73149LKTq5VMTTj9EOa3KMdo7W0f0R EvuRFM8OOgGjhOeSh9w/DV6S8AlxEWMgfevXWXWCuPAAjnGT8bYHLAA+bRvrzp33p9el 5jUuHHGTZc7mHk8xw2sBOIPpOBtBygymIsEtiC1tmcNdpHHAvHSzxNt7y0PrkvKdKn59 e6VmZVciF8VaxEv06APf2+VvxWbcN4qnzPi5wDDM/C8fWzYC5bCANSAGJBgLsWPtInoO 4eIw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h13si4278852pgs.17.2019.01.18.07.12.41; Fri, 18 Jan 2019 07:12:58 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727826AbfARPKY (ORCPT + 99 others); Fri, 18 Jan 2019 10:10:24 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:44058 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1727608AbfARPKX (ORCPT ); Fri, 18 Jan 2019 10:10:23 -0500 Received: (qmail 2300 invoked by uid 2102); 18 Jan 2019 10:10:22 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Jan 2019 10:10:22 -0500 Date: Fri, 18 Jan 2019 10:10:22 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Andrea Parri cc: LKMM Maintainers -- Akira Yokosawa , Boqun Feng , Daniel Lustig , David Howells , Jade Alglave , Luc Maranget , Nicholas Piggin , "Paul E. McKenney" , Peter Zijlstra , Will Deacon , Dmitry Vyukov , Nick Desaulniers , Subject: Re: Plain accesses and data races in the Linux Kernel Memory Model In-Reply-To: <20190117150336.GA10381@andrea> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 17 Jan 2019, Andrea Parri wrote: > > Can the compiler (maybe, it does?) transform, at the C or at the "asm" > > level, LB1's P0 in LB2's P0 (LB1 and LB2 are reported below)? > > > > C LB1 > > > > { > > int *x = &a; > > } > > > > P0(int **x, int *y) > > { > > int *r0; > > > > r0 = rcu_dereference(*x); > > *r0 = 0; > > smp_wmb(); > > WRITE_ONCE(*y, 1); > > } > > > > P1(int **x, int *y, int *b) > > { > > int r0; > > > > r0 = READ_ONCE(*y); > > rcu_assign_pointer(*x, b); > > } > > > > exists (0:r0=b /\ 1:r0=1) > > > > > > C LB2 > > > > { > > int *x = &a; > > } > > > > P0(int **x, int *y) > > { > > int *r0; > > > > r0 = rcu_dereference(*x); > > if (*r0) > > *r0 = 0; > > smp_wmb(); > > WRITE_ONCE(*y, 1); > > } > > > > P1(int **x, int *y, int *b) > > { > > int r0; > > > > r0 = READ_ONCE(*y); > > rcu_assign_pointer(*x, b); > > } > > > > exists (0:r0=b /\ 1:r0=1) > > > > LB1 and LB2 are data-race free, according to the patch; LB1's "exists" > > clause is not satisfiable, while LB2's "exists" clause is satisfiable. A relatively simple solution to this problem would be to say that smp_wmb doesn't order plain writes. I think the rest of the memory model would then be okay. However, I am open to arguments that this approach is too complex and we should insist on the same kind of strict ordering for race avoidance that the C11 standard uses (i.e., conflicting accesses separated by full memory barriers or release & acquire barriers or locking). Alan