[lkml]   [2010]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH tip/core/rcu 0/21] v6 add lockdep-based diagnostics to rcu_dereference()
    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.


     \ /
      Last update: 2010-02-23 16:57    [W:0.037 / U:1.228 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site