RCU condition checks

From: David Howells
Date: Wed Apr 07 2010 - 12:35:56 EST

Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> wrote:

> > Why is there a need for 'c'?
> An example use is where rcu_access_pointer() is legal because we are
> either initializing or cleaning up, so that no other CPU has access
> to the pointer. In these cases, you might do something like:
> q = rcu_access_pointer(p->a, p->refcnt == 0);

I think the main problem I have with this is that the fact that p->refcnt
should be 0 here is unrelated to the fact that we're wanting to look at the
value of p->a. I'd say that this should be two separate statements, for

ASSERT(p->refcnt == 0);
q = rcu_access_pointer(p->a);

I could see using a lockdep-managed ASSERT here would work, though.

The other problem I have with this is that I'm assuming rcu_access_pointer()
is simply for looking at the value of the pointer without dereferencing it -
in which case, is there any need for the lock-describing condition?

I agree, though, that:

q = rcu_dereference_check(p->a,
rcu_read_lock_held() || (
lockdep_is_held(p->lock) &&

is a reasonable way of keeping the dereference and the lock checks together,
though that could equally well be written, say:

LOCKDEP_ASSERT(rcu_read_lock_held() || (
lockdep_is_held(p->lock) &&
q = rcu_dereference_protected(p->a);

but combining those makes it easier to ensure people to write lock checking.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/