Messages in this thread | | | Subject | Re: [patch 01/15] Kernel Tracepoints | From | Peter Zijlstra <> | Date | Sat, 02 Aug 2008 02:03:57 +0200 |
| |
On Fri, 2008-08-01 at 14:10 -0700, Paul E. McKenney wrote:
> Yeah, I was thinking in terms of rcu_dereference() working with both > rcu_assign_pointer() and an as-yet-mythical rcu_assign_index(). Perhaps > this would be a good time to get better names: > > Current: rcu_assign_pointer() rcu_dereference() > New Pointers: rcu_publish_pointer() rcu_subscribe_pointer() > New Indexes: rcu_publish_index() rcu_subscribe_index()
Is it really worth the effort, splitting it out into these two cases?
> And, while I am at it, work in a way of checking for either being in > the appropriate RCU read-side critical section and/or having the > needed lock/mutex/whatever held -- something I believe PeterZ was > prototyping some months back.
Yeah - I have (bitrotted a bit, but should be salvageable) lockdep annotations for rcu_dereference().
The problem with them is the huge amount of false positives.. Take for example the Radix tree code, its perfectly fine to use the radix tree code without RCU - say you do the old rwlock style, still it uses rcu_dereference().
I never figured out a suitable way to annotate that.
| |