RCU and lockdep checking¶

All flavors of RCU have lockdep checking available, so that lockdep isaware of when each task enters and leaves any flavor of RCU read-sidecritical section. Each flavor of RCU is tracked separately (but notethat this is not the case in 2.6.32 and earlier). This allows lockdep’stracking to include RCU state, which can sometimes help when debuggingdeadlocks and the like.

In addition, RCU provides the following primitives that check lockdep’sstate:

rcu_read_lock_held() for normal RCU.rcu_read_lock_bh_held() for RCU-bh.rcu_read_lock_sched_held() for RCU-sched.rcu_read_lock_any_held() for any of normal RCU, RCU-bh, and RCU-sched.srcu_read_lock_held() for SRCU.rcu_read_lock_trace_held() for RCU Tasks Trace.

These functions are conservative, and will therefore return 1 if theyaren’t certain (for example, if CONFIG_DEBUG_LOCK_ALLOC is not set).This prevents things like WARN_ON(!rcu_read_lock_held()) from giving falsepositives when lockdep is disabled.

In addition, a separate kernel config parameter CONFIG_PROVE_RCU enableschecking ofrcu_dereference() primitives:

rcu_dereference(p):

Check for RCU read-side critical section.

rcu_dereference_bh(p):

Check for RCU-bh read-side critical section.

rcu_dereference_sched(p):

Check for RCU-sched read-side critical section.

srcu_dereference(p, sp):

Check for SRCU read-side critical section.

rcu_dereference_check(p, c):

Use explicit check expression “c” along withrcu_read_lock_held(). This is useful in code that isinvoked by both RCU readers and updaters.

rcu_dereference_bh_check(p, c):

Use explicit check expression “c” along withrcu_read_lock_bh_held(). This is useful in code thatis invoked by both RCU-bh readers and updaters.

rcu_dereference_sched_check(p, c):

Use explicit check expression “c” along withrcu_read_lock_sched_held(). This is useful in code thatis invoked by both RCU-sched readers and updaters.

srcu_dereference_check(p, c):

Use explicit check expression “c” along withsrcu_read_lock_held(). This is useful in code thatis invoked by both SRCU readers and updaters.

rcu_dereference_raw(p):

Don’t check. (Use sparingly, if at all.)

rcu_dereference_raw_check(p):

Don’t do lockdep at all. (Use sparingly, if at all.)

rcu_dereference_protected(p, c):

Use explicit check expression “c”, and omit all barriersand compiler constraints. This is useful when the datastructure cannot change, for example, in code that isinvoked only by updaters.

rcu_access_pointer(p):

Return the value of the pointer and omit all barriers,but retain the compiler constraints that prevent duplicatingor coalescing. This is useful when testing thevalue of the pointer itself, for example, against NULL.

Thercu_dereference_check() check expression can be any booleanexpression, but would normally include a lockdep expression. For amoderately ornate example, consider the following:

file = rcu_dereference_check(fdt->fd[fd],                             lockdep_is_held(&files->file_lock) ||                             atomic_read(&files->count) == 1);

This expression picks up the pointer “fdt->fd[fd]” in an RCU-safe manner,and, if CONFIG_PROVE_RCU is configured, verifies that this expressionis used in:

1. An RCU read-side critical section (implicit), or

2. with files->file_lock held, or

3. on an unshared files_struct.

In case (1), the pointer is picked up in an RCU-safe manner for vanillaRCU read-side critical sections, in case (2) the ->file_lock preventsany change from taking place, and finally, in case (3) the current taskis the only task accessing the file_struct, again preventing any changefrom taking place. If the above statement was invoked only from updatercode, it could instead be written as follows:

file = rcu_dereference_protected(fdt->fd[fd],                                 lockdep_is_held(&files->file_lock) ||                                 atomic_read(&files->count) == 1);

This would verify cases #2 and #3 above, and furthermore lockdep wouldcomplain even if this was used in an RCU read-side critical section unlessone of these two cases held. Becausercu_dereference_protected() omitsall barriers and compiler constraints, it generates better code than dothe other flavors ofrcu_dereference(). On the other hand, it is illegalto usercu_dereference_protected() if either the RCU-protected pointeror the RCU-protected data that it points to can change concurrently.

Likercu_dereference(), when lockdep is enabled, RCU list and hlisttraversal primitives check for being called from within an RCU read-sidecritical section. However, a lockdep expression can be passed to themas an additional optional argument. With this lockdep expression, thesetraversal primitives will complain only if the lockdep expression isfalse and they are called from outside any RCU read-side critical section.

For example, the workqueuefor_each_pwq() macro is intended to be usedeither within an RCU read-side critical section or with wq->mutex held.It is thus implemented as follows:

#define for_each_pwq(pwq, wq)        list_for_each_entry_rcu((pwq), &(wq)->pwqs, pwqs_node,                                lock_is_held(&(wq->mutex).dep_map))