From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753567AbdJMUAk (ORCPT ); Fri, 13 Oct 2017 16:00:40 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:50120 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753257AbdJMUAi (ORCPT ); Fri, 13 Oct 2017 16:00:38 -0400 Date: Fri, 13 Oct 2017 13:00:33 -0700 From: "Paul E. McKenney" To: Alan Stern Cc: Andrea Parri , Will Deacon , peterz@infradead.org, boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com, Jade Alglave , Luc Maranget , Kernel development list Subject: Re: Linux-kernel examples for LKMM recipes Reply-To: paulmck@linux.vnet.ibm.com References: <20171011223229.GA31650@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17101320-0008-0000-0000-00000290987E X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007892; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000236; SDB=6.00930689; UDB=6.00468529; IPR=6.00710956; BA=6.00005636; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017531; XFM=3.00000015; UTC=2017-10-13 20:00:36 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17101320-0009-0000-0000-000036FFA2BB Message-Id: <20171013200033.GI3521@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-13_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710130279 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 13, 2017 at 03:44:07PM -0400, Alan Stern wrote: > On Wed, 11 Oct 2017, Paul E. McKenney wrote: > > > This document lists the litmus-test patterns that we have been discussing, > > along with examples from the Linux kernel. This is intended to feed into > > the recipes document. All examples are from v4.13. > > > > 0. Single-variable SC. > > > > a. Within a single CPU, the use of the ->dynticks_nmi_nesting > > counter by rcu_nmi_enter() and rcu_nmi_exit() qualifies > > (see kernel/rcu/tree.c). The counter is accessed by > > interrupts and NMIs as well as by process-level code. > > This counter can be accessed by other CPUs, but only > > for debug output. > > I'm not sure that single-variable SC can really be represented by an > example. It gets used literally all over the kernel -- it's such a > large part of the way we think about computer programs that we rely on > it unconsciously. > > For example, the very first function in the very first C source file > in the kernel/ directory (namely, check_free_space() in kernel/acct.c) > includes this code: > > if (acct->active) { > u64 suspend = sbuf.f_blocks * SUSPEND; > do_div(suspend, 100); > > How do we know that the value which gets divided by 100 is > sbuf.f_blocks * SUSPEND and not the random garbage which was stored in > suspend's memory location before it was initialized? Answer: > per-variable SC. > > Okay, maybe that's not really applicable, since it doesn't involve > accesses to shared memory. Here's an example that does. > get_futex_key() in kernel/futex.c calls READ_ONCE(page->mapping) twice. > How do we know that the value retrieved by the second call was not > stored _earlier_ than the value retrieved by the first call? > Per-variable SC. > > > b. Between CPUs, I would put forward the ->dflags > > updates, but this is anything but simple. But maybe > > OK for an illustration? > > Pretty much any code that accesses the same shared variable twice on > the same CPU could be an example of per-variable SC. But I don't think > people would learn much by studying such examples. Perhaps the recipes document should just baldly state that any execution having only one thread and/or having only one variable will be fully ordered? Thanx, Paul