linux-kernel - Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical sections

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 1 Mar 2016 10:57:07 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Boqun Feng <boqun.feng@...il.com>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	Josh Triplett <josh@...htriplett.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Lai Jiangshan <jiangshanlai@...il.com>, sasha.levin@...cle.com
Subject: Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical
 sections

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.