Messages in this thread | | | Date | Fri, 1 Aug 2008 17:17:11 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [patch 01/15] Kernel Tracepoints |
| |
On Sat, Aug 02, 2008 at 02:03:57AM +0200, Peter Zijlstra wrote: > 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?
Either we should split out into the pointer/index cases, or the definition of rcu_assign_pointer() should probably lose its current check for NULL...
> > 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.
My thought was to add a second argument that contained a boolean. If the rcu_dereference() was either within an RCU read-side critical section on the one hand or if the boolean evaluated to "true" on the other, then no assertion. This would require SPIN_LOCK_HELD() or similar primitives. (And one of the reasons for the renaming
Of course, in the case of radix tree, it would be necessary to pass the boolean in through the radix-tree read-side APIs, which would perhaps be a bit annoying.
Thanx, Paul
| |