From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752928AbcCAJ5P (ORCPT ); Tue, 1 Mar 2016 04:57:15 -0500 Received: from casper.infradead.org ([85.118.1.10]:55803 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752130AbcCAJ5N (ORCPT ); Tue, 1 Mar 2016 04:57:13 -0500 Date: Tue, 1 Mar 2016 10:57:07 +0100 From: Peter Zijlstra To: Boqun Feng Cc: "Paul E. McKenney" , linux-kernel@vger.kernel.org, Ingo Molnar , Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , sasha.levin@oracle.com Subject: Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical sections Message-ID: <20160301095707.GP6356@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160301093242.GA29874@fixme-laptop.cn.ibm.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 I'm still not sure this is useful. Also, I would argue your code has > > > > problems if you cannot even find your rcu_read_lock(). > > > > > > > > > > I think what you mean here is, for example, the case where we use > > > preempt_disable() instead of rcu_read_lock_sched() to pair with > > > synchronize_sched(), right? > > > > No, I was more like: > > > > rcu_read_lock(); > > foo() > > bar() > > var->func(); > > obj->func(); > > whatever(); > > > > and you're looking at a change to whatever() and wonder where the heck > > the corresponding rcu_read_lock() lives and if we're having it held at > > all. > > > > Confused.. RCU_LOCKED_ACCESS has such information, For example, in the > piece of /proc/locked_access/rcu I put in the cover letter, which I will > put in the commit logs for the next version of this series: Yes, but my point was that if it wasn't obvious from the code, your code has issues. You should not be needing a tool to figure this out.