Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1347809

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

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On Tue, Mar 01, 2016 at 11:01:34AM +0100, Peter Zijlstra wrote:
> 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.
> 

Another problem of taking the absolute address is the address may change
from rcu_annotate() to rcu_dereference() for example:

	rcu_read_lock();
	rcu_annotate(&var->field);
					// in another thread
					var = new_var;
	
	// the address of var->field is different now.
	rcu_dereference(var->field);
	rcu_read_unlock();


> 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.
> 

Well, some of them have rcu_head, but not all.. so you're right.

> 

I come up with something you may not like ;-) , which is taking the
strings of the expressions, for example:

	rcu_read_lock();
	rcu_annotate(var->field);	// "var->field" is added for 
					// the current section

	rcu_dereference(var->field);	// OK, because the expression
					// "var->field" is annotated.

	rcu_dereference(var->field2);	// Not OK, because the
					// expression "var->field2" is
					// not annotated, nor is any of
					// its suffix.

	rcu_annotate(field3);		// "field3" is added for the
					// current section
	
	rcu_dereference(var2->field3);	// OK, because the suffix
					// "field3" is annotated.
	rcu_read_unlock();

I think this is more accurate than taking the absolute address because
the address changing situations exist. So.. thoughts?

Regards,
Boqun

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical  sections Peter Zijlstra <peterz@infradead.org> - 2016-02-25 15:40 +0100
  Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical  sections "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-25 16:40 +0100
    Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical  sections Boqun Feng <boqun.feng@gmail.com> - 2016-02-26 04:10 +0100
      Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical  sections Peter Zijlstra <peterz@infradead.org> - 2016-02-26 12:30 +0100
        Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical  sections Boqun Feng <boqun.feng@gmail.com> - 2016-02-29 02:20 +0100
          Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical  sections Peter Zijlstra <peterz@infradead.org> - 2016-02-29 13:50 +0100
            Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical  sections Boqun Feng <boqun.feng@gmail.com> - 2016-03-01 10:40 +0100
              Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical  sections Peter Zijlstra <peterz@infradead.org> - 2016-03-01 11:00 +0100
                Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical  sections Peter Zijlstra <peterz@infradead.org> - 2016-03-01 11:10 +0100
                Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical  sections Boqun Feng <boqun.feng@gmail.com> - 2016-03-02 07:40 +0100
                Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical  sections Peter Zijlstra <peterz@infradead.org> - 2016-03-02 11:20 +0100
                Re: [RFC v2 0/6] Track RCU dereferences in RCU read-side critical  sections "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-03-02 15:10 +0100

csiph-web