From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752908AbcCAKBk (ORCPT <rfc822;w@1wt.eu>);
	Tue, 1 Mar 2016 05:01:40 -0500
Received: from casper.infradead.org ([85.118.1.10]:55900 "EHLO
	casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750933AbcCAKBh (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 1 Mar 2016 05:01:37 -0500
Date: Tue, 1 Mar 2016 11:01:34 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
        Josh Triplett <josh@joshtriplett.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
        Lai Jiangshan <jiangshanlai@gmail.com>, sasha.levin@oracle.com
Subject: Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical
 sections
Message-ID: <20160301100134.GW6375@twins.programming.kicks-ass.net>
References: <1455602265-16490-1-git-send-email-boqun.feng@gmail.com>
 <20160225143243.GP6357@twins.programming.kicks-ass.net>
 <20160225153724.GL3522@linux.vnet.ibm.com>
 <20160226030627.GA2431@fixme-laptop.cn.ibm.com>
 <20160226112521.GZ6356@twins.programming.kicks-ass.net>
 <20160229011220.GA1583@fixme-laptop.cn.ibm.com>
 <20160229124318.GM6356@twins.programming.kicks-ass.net>
 <20160301093242.GA29874@fixme-laptop.cn.ibm.com>
 <20160301095707.GP6356@twins.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160301095707.GP6356@twins.programming.kicks-ass.net>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Mar 01, 2016 at 10:57:07AM +0100, Peter Zijlstra wrote:
> On Tue, Mar 01, 2016 at 05:32:42PM +0800, Boqun Feng wrote:
> > > One could for example allow something like:
> > > 
> > > 	rcu_read_lock();
> > > 	rcu_annotate(&var->field);
> > > 
> > > 	foo();
> > > 
> > > 	rcu_read_unlock();
> > > 
> > > As an alternative to the syntax suggested by Ingo. This would allow
> > > keeping the existing rcu_read_lock() signature so you don't have to
> > > force update the entire kernel at once, while also (easily) allowing
> > > multiple variables. Like:
> > > 
> > > 	rcu_read_lock();
> > > 	rcu_annotate(&var->field);
> > > 	rcu_annotate(&var2->field2);
> > > 
> > > You can then have a special rule that if a particular RCU section has an
> > > annotation, any rcu_dereference() not matched will field a warning. If
> > > the annotation section is empty, nothing.
> > > 
> > 
> > Good idea! but I don't think annotating a field in C language is easy,
> > I will try to see what we can get. Do you have something already in your
> > mind?
> 
> No, didn't really think about that :-/ The most restrictive version is
> taking the absolute address, but that would make things like actual data
> structures impossible.

So the thing with locks is they get a struct lockdep_map added, in which
we store all kinds of useful. But I don't think we cannot add a similar
structure to each and every RCU dereferencable (is that a word?)
variable.