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.