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.