1RCU and lockdep checking
   3All flavors of RCU have lockdep checking available, so that lockdep is
   4aware of when each task enters and leaves any flavor of RCU read-side
   5critical section.  Each flavor of RCU is tracked separately (but note
   6that this is not the case in 2.6.32 and earlier).  This allows lockdep's
   7tracking to include RCU state, which can sometimes help when debugging
   8deadlocks and the like.
  10In addition, RCU provides the following primitives that check lockdep's
  13        rcu_read_lock_held() for normal RCU.
  14        rcu_read_lock_bh_held() for RCU-bh.
  15        rcu_read_lock_sched_held() for RCU-sched.
  16        srcu_read_lock_held() for SRCU.
  18These functions are conservative, and will therefore return 1 if they
  19aren't certain (for example, if CONFIG_DEBUG_LOCK_ALLOC is not set).
  20This prevents things like WARN_ON(!rcu_read_lock_held()) from giving false
  21positives when lockdep is disabled.
  23In addition, a separate kernel config parameter CONFIG_PROVE_RCU enables
  24checking of rcu_dereference() primitives:
  26        rcu_dereference(p):
  27                Check for RCU read-side critical section.
  28        rcu_dereference_bh(p):
  29                Check for RCU-bh read-side critical section.
  30        rcu_dereference_sched(p):
  31                Check for RCU-sched read-side critical section.
  32        srcu_dereference(p, sp):
  33                Check for SRCU read-side critical section.
  34        rcu_dereference_check(p, c):
  35                Use explicit check expression "c" along with
  36                rcu_read_lock_held().  This is useful in code that is
  37                invoked by both RCU readers and updaters.
  38        rcu_dereference_bh_check(p, c):
  39                Use explicit check expression "c" along with
  40                rcu_read_lock_bh_held().  This is useful in code that
  41                is invoked by both RCU-bh readers and updaters.
  42        rcu_dereference_sched_check(p, c):
  43                Use explicit check expression "c" along with
  44                rcu_read_lock_sched_held().  This is useful in code that
  45                is invoked by both RCU-sched readers and updaters.
  46        srcu_dereference_check(p, c):
  47                Use explicit check expression "c" along with
  48                srcu_read_lock_held()().  This is useful in code that
  49                is invoked by both SRCU readers and updaters.
  50        rcu_dereference_index_check(p, c):
  51                Use explicit check expression "c", but the caller
  52                must supply one of the rcu_read_lock_held() functions.
  53                This is useful in code that uses RCU-protected arrays
  54                that is invoked by both RCU readers and updaters.
  55        rcu_dereference_raw(p):
  56                Don't check.  (Use sparingly, if at all.)
  57        rcu_dereference_protected(p, c):
  58                Use explicit check expression "c", and omit all barriers
  59                and compiler constraints.  This is useful when the data
  60                structure cannot change, for example, in code that is
  61                invoked only by updaters.
  62        rcu_access_pointer(p):
  63                Return the value of the pointer and omit all barriers,
  64                but retain the compiler constraints that prevent duplicating
  65                or coalescsing.  This is useful when when testing the
  66                value of the pointer itself, for example, against NULL.
  68The rcu_dereference_check() check expression can be any boolean
  69expression, but would normally include a lockdep expression.  However,
  70any boolean expression can be used.  For a moderately ornate example,
  71consider the following:
  73        file = rcu_dereference_check(fdt->fd[fd],
  74                                     lockdep_is_held(&files->file_lock) ||
  75                                     atomic_read(&files->count) == 1);
  77This expression picks up the pointer "fdt->fd[fd]" in an RCU-safe manner,
  78and, if CONFIG_PROVE_RCU is configured, verifies that this expression
  79is used in:
  811.      An RCU read-side critical section (implicit), or
  822.      with files->file_lock held, or
  833.      on an unshared files_struct.
  85In case (1), the pointer is picked up in an RCU-safe manner for vanilla
  86RCU read-side critical sections, in case (2) the ->file_lock prevents
  87any change from taking place, and finally, in case (3) the current task
  88is the only task accessing the file_struct, again preventing any change
  89from taking place.  If the above statement was invoked only from updater
  90code, it could instead be written as follows:
  92        file = rcu_dereference_protected(fdt->fd[fd],
  93                                         lockdep_is_held(&files->file_lock) ||
  94                                         atomic_read(&files->count) == 1);
  96This would verify cases #2 and #3 above, and furthermore lockdep would
  97complain if this was used in an RCU read-side critical section unless one
  98of these two cases held.  Because rcu_dereference_protected() omits all
  99barriers and compiler constraints, it generates better code than do the
 100other flavors of rcu_dereference().  On the other hand, it is illegal
 101to use rcu_dereference_protected() if either the RCU-protected pointer
 102or the RCU-protected data that it points to can change concurrently.
 104There are currently only "universal" versions of the rcu_assign_pointer()
 105and RCU list-/tree-traversal primitives, which do not (yet) check for
 106being in an RCU read-side critical section.  In the future, separate
 107versions of these primitives might be created.
 108 kindly hosted by Redpill Linpro AS, provider of Linux consulting and operations services since 1995.