Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp4477499imm; Tue, 11 Sep 2018 12:32:17 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYN4E4EN6/VWVuXMjL5kKDixwbKex4rZpIc1yEGwiKQEjd6DnvhrnwyqdTo6ezgrUKX7Ovg X-Received: by 2002:a65:668f:: with SMTP id b15-v6mr27503680pgw.426.1536694337061; Tue, 11 Sep 2018 12:32:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536694337; cv=none; d=google.com; s=arc-20160816; b=u/w3uge4M7WBmcJ1ZuPmuzB/gKfzmhmIkcuMDPh+3AcheVfqDBS8LE1BHUHg4snSdg e8FvSZ0qD0V6B3CSvNLDw0fSmvA5Birftgu3ZG33Ux9yBZSSEB9X9vS47V4rVNKYLDwG V07WhqstrNWggS8SKIW5D3zjWtTekoUtsnwSWtVURNo+nHOol9DR0NLVWpURKscu2wlV dDGJW1ezTWsI6hNnJxPCs3J+9QXowM8tJLSpRBf1iC33/O2KhIkdHZuJbaSkEITWCdgW CcDpk8WyS+7eA7qc57rtNDQYlwty1jeENhdZtGYgZjCbmy3l53D+9x0UJNmz8vC0pmKu DS2A== 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=DaZ4+BZXFv6SaKo/gaamgdyHowTM8nx3mF4bi0FGa4s=; b=uGuKq8Q4kNWk1U/ugexyDdNRSpu5bxgczYNQnkjAvaSCWgy7ildR3ptS5ty6RddVXD UTot8HbiyO5GNUGUZLj7cKjJ/WSTkyQ7qUNS2nQFJCJxSma8p0nSpvNOAemERIoTMXGu KToPi6x6/fVEw8m6YK4GurdirYtGt4UU5SPi6OLZv/kv1JEcLgfsw/BoT2LQN0xA4orA xK5bioeuTdExfgef1Gn8F7qwUbudI2dPWPFeRjdXqpqjzQmV2jK//7MMFoUwfDnHgXbm mIVpcjGKq/WOxSbxJQHirlefUHOlnMZWMswgzshmoM7k5PnI4KuyBx4qy9iU0PCudD+5 RJYA== 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 l2-v6si21422431pfb.69.2018.09.11.12.32.01; Tue, 11 Sep 2018 12:32:17 -0700 (PDT) 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 S1727689AbeILAcj (ORCPT + 99 others); Tue, 11 Sep 2018 20:32:39 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:50074 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726689AbeILAcj (ORCPT ); Tue, 11 Sep 2018 20:32:39 -0400 Received: (qmail 5674 invoked by uid 2102); 11 Sep 2018 15:31:53 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Sep 2018 15:31:53 -0400 Date: Tue, 11 Sep 2018 15:31:53 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: "Paul E. McKenney" cc: Daniel Lustig , Will Deacon , Andrea Parri , Andrea Parri , Kernel development list , , , , , , , Jade Alglave , Luc Maranget , , Palmer Dabbelt Subject: Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire In-Reply-To: <20180908095848.GA6272@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, 12 Jul 2018, Paul E. McKenney wrote: > > > Take for instance the pattern where RCU relies on RCsc locks, this is an > > > entirely simple and straight forward use of locks, yet completely fails > > > on this subtle point. > > > > Do you happen to remember exactly where in the kernel source this > > occurs? > > Look for the uses of raw_spin_lock_irq_rcu_node() and friends in > kernel/rcu and include/linux/*rcu*, along with the explanation in > Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.html I just now started looking at this for the first time, and I was struck by the sloppy thinking displayed in the very first paragraph of the HTML document! For example, consider the third sentence: Similarly, any code that happens before the beginning of a given RCU grace period is guaranteed to see the effects of all accesses following the end of that grace period that are within RCU read-side critical sections. Is RCU now a time machine? :-) I think what you meant to write in the second and third sentences was something more like this: Any code in an RCU critical section that extends beyond the end of a given RCU grace period is guaranteed to see the effects of all accesses which were visible to the grace period's CPU before the start of the grace period. Similarly, any code that follows an RCU grace period (on the grace period's CPU) is guaranteed to see the effects of all accesses which were visible to an RCU critical section that began before the start of the grace period. Also, the document doesn't seem to explain how Tree RCU relies on the lock-ordering guarantees of raw_spin_lock_rcu_node() and friends. It _says_ that these guarantees are used, but not how or where. (Unless I missed something; I didn't read the document all that carefully.) In any case, you should bear in mind that the lock ordering provided by Peter's raw_spin_lock_rcu_node() and friends is not the same as what we have been discussing for the LKMM: Peter's routines are meant for the case where you release one lock and then acquire another (for example, locks in two different levels of the RCU tree). The LKMM patch applies only to cases where one CPU releases a lock and then that CPU or another acquires the _same_ lock again. As another difference, the litmus test given near the start of the "Tree RCU Grace Period Memory Ordering Building Blocks" section would not be forbidden by the LKMM, even with RCtso locks, if it didn't use raw_spin_lock_rcu_node(). This is because the litmus test is forbidden only when locks are RCsc, which is what raw_spin_lock_rcu_node() provides. So I don't see how the RCU code can be held up as an example either for or against requiring locks to be RCtso. Alan