Re: [PATCH tip/core/rcu 0/21] v6 add lockdep-based diagnostics to rcu_dereference()

[Arnd Bergmann]

On Tuesday 23 February 2010, Mathieu Desnoyers wrote:
> Just to make myself the devil's advocate: how should we consider
> initialization of RCU pointers at boot time that happens before any
> possible concurrent reader is allowed to run ? I think this case is an
> example of valid RCU-pointer access that is not done through the RCU
> primitives. It seems valid to perform these RCU-pointer accesses when
> serialized by a different exclusion mechanism, in this case being the
> guarantee that no concurrent reader are running at early boot.

Like the annotations adding __rcu to each rcu protected pointer, we'd
also have to add annotations to static initialization of those. E.g.
something like 

#define DEFINE_RCU_VAR(type, name, pointer) \
	type __rcu *name = (__force type)pointer

should do for simple initializations, and I guess I can come up
with similar solutions if we need something more fancy.

> The same applies to stop_machine(), and, as I come to think of it, we could
> probably think of a scheme that dynamically switch from an RCU read-lock
> to, e.g., a mutex for all users, wait for RCU quiescent state, and then
> serialize all users on the mutex during the update. So while some of
> these cases are a bit far-fetched, I think they are valid, and I wonder
> how the address space validation would take them into account.

I assume that it's never wrong to do a pointer assignment using
rcu_assign_pointer, or to do a dereference using rcu_dereference,
even if you hold a mutex or stop_machine. I would also guess that
the performance impact of doing so is not measurable. If both are
true for all corner cases, we could just use the rcu primitives
for any access on those variables for consistency reasons.

If there are cases where it does not work, we need to come up with
names for new primitives that just do the assignment or dereference
with __force but no actual synchronization.

	Arnd
--
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/