From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:56094 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752720AbdKTVVJ (ORCPT ); Mon, 20 Nov 2017 16:21:09 -0500 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAKLK8tq091984 for ; Mon, 20 Nov 2017 16:21:08 -0500 Received: from e13.ny.us.ibm.com (e13.ny.us.ibm.com [129.33.205.203]) by mx0b-001b2d01.pphosted.com with ESMTP id 2ec4g0pwpb-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 20 Nov 2017 16:21:08 -0500 Received: from localhost by e13.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 20 Nov 2017 16:21:07 -0500 Date: Mon, 20 Nov 2017 13:21:07 -0800 From: "Paul E. McKenney" To: Luc Van Oostenryck Cc: Matthew Wilcox , Tim Hansen , Al Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds , alexander.levin@one.verizon.com Subject: Re: [PATCH] fs: Safe rcu access to hlist. Reply-To: paulmck@linux.vnet.ibm.com References: <20171119200210.hhrklgm6hxhoyhqh@debian> <20171119212849.GV21978@ZenIV.linux.org.uk> <20171120185535.ggmnui2ud3ixqw7g@debian> <20171120200130.xhfj6zeczg3jfhcx@ltop.local> <20171120204253.GA8933@bombadil.infradead.org> <20171120205801.dtqloltgfxkmfxee@ltop.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171120205801.dtqloltgfxkmfxee@ltop.local> Message-Id: <20171120212107.GB3624@linux.vnet.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Nov 20, 2017 at 09:58:02PM +0100, Luc Van Oostenryck wrote: > On Mon, Nov 20, 2017 at 12:42:53PM -0800, Matthew Wilcox wrote: > > > > I disagree. The notion of whether a pointer is protected by RCU or not > > is definitely not transient. > > Sure. But what about the memory it points to? > It's just 'normal' kernel memory, there is nowhere > something like some 'RCU memory', right? > > And the memory accessed through a __rcu annotated > pointer can be legally be accessed with normal > memory operation, because it's only the pointer that > is concerned by the annotation? It is the dereferencing of the pointer that is important. For the pointer itself, once we have loaded it, we have loaded it, and that is that. The ordering that must be preserved is the load of the pointer against later loads dereferencing that pointer. Now you might ask, as I once did, "How can the later dereference possibly be reordered against the pointer being dereferenced?" And the answer is that DEC Alpha really did such reordering, and also that feedback-based optimizations could potentially cause compilers to do such reordering. There is a lot written on this topic, but Documentation/RCU/rcu_dereference.txt and Documentation/memory-barriers.txt are reasonable places to start. Or, for more recent but still experimental documentation, the file Documentation/explanation.txt at https://github.com/aparri/memory-model. In short, sparse's approach really does make sense here. Thanx, Paul