^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) RCU and lockdep checking
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) ========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) All flavors of RCU have lockdep checking available, so that lockdep is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) aware of when each task enters and leaves any flavor of RCU read-side
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) critical section. Each flavor of RCU is tracked separately (but note
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) that this is not the case in 2.6.32 and earlier). This allows lockdep's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) tracking to include RCU state, which can sometimes help when debugging
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) deadlocks and the like.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) In addition, RCU provides the following primitives that check lockdep's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) state::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) rcu_read_lock_held() for normal RCU.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) rcu_read_lock_bh_held() for RCU-bh.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) rcu_read_lock_sched_held() for RCU-sched.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) srcu_read_lock_held() for SRCU.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) These functions are conservative, and will therefore return 1 if they
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) aren't certain (for example, if CONFIG_DEBUG_LOCK_ALLOC is not set).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) This prevents things like WARN_ON(!rcu_read_lock_held()) from giving false
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) positives when lockdep is disabled.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) In addition, a separate kernel config parameter CONFIG_PROVE_RCU enables
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) checking of rcu_dereference() primitives:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) rcu_dereference(p):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) Check for RCU read-side critical section.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) rcu_dereference_bh(p):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) Check for RCU-bh read-side critical section.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) rcu_dereference_sched(p):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) Check for RCU-sched read-side critical section.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) srcu_dereference(p, sp):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) Check for SRCU read-side critical section.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) rcu_dereference_check(p, c):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) Use explicit check expression "c" along with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) rcu_read_lock_held(). This is useful in code that is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) invoked by both RCU readers and updaters.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) rcu_dereference_bh_check(p, c):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) Use explicit check expression "c" along with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) rcu_read_lock_bh_held(). This is useful in code that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) is invoked by both RCU-bh readers and updaters.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) rcu_dereference_sched_check(p, c):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) Use explicit check expression "c" along with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) rcu_read_lock_sched_held(). This is useful in code that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) is invoked by both RCU-sched readers and updaters.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) srcu_dereference_check(p, c):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) Use explicit check expression "c" along with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) srcu_read_lock_held(). This is useful in code that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) is invoked by both SRCU readers and updaters.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) rcu_dereference_raw(p):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) Don't check. (Use sparingly, if at all.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) rcu_dereference_protected(p, c):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) Use explicit check expression "c", and omit all barriers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) and compiler constraints. This is useful when the data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) structure cannot change, for example, in code that is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) invoked only by updaters.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) rcu_access_pointer(p):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) Return the value of the pointer and omit all barriers,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) but retain the compiler constraints that prevent duplicating
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) or coalescsing. This is useful when when testing the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) value of the pointer itself, for example, against NULL.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) The rcu_dereference_check() check expression can be any boolean
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) expression, but would normally include a lockdep expression. However,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) any boolean expression can be used. For a moderately ornate example,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) consider the following::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) file = rcu_dereference_check(fdt->fd[fd],
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) lockdep_is_held(&files->file_lock) ||
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) atomic_read(&files->count) == 1);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) This expression picks up the pointer "fdt->fd[fd]" in an RCU-safe manner,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) and, if CONFIG_PROVE_RCU is configured, verifies that this expression
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) is used in:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) 1. An RCU read-side critical section (implicit), or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) 2. with files->file_lock held, or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) 3. on an unshared files_struct.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) In case (1), the pointer is picked up in an RCU-safe manner for vanilla
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) RCU read-side critical sections, in case (2) the ->file_lock prevents
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) any change from taking place, and finally, in case (3) the current task
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) is the only task accessing the file_struct, again preventing any change
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) from taking place. If the above statement was invoked only from updater
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) code, it could instead be written as follows::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) file = rcu_dereference_protected(fdt->fd[fd],
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) lockdep_is_held(&files->file_lock) ||
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) atomic_read(&files->count) == 1);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) This would verify cases #2 and #3 above, and furthermore lockdep would
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) complain if this was used in an RCU read-side critical section unless one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) of these two cases held. Because rcu_dereference_protected() omits all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) barriers and compiler constraints, it generates better code than do the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) other flavors of rcu_dereference(). On the other hand, it is illegal
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) to use rcu_dereference_protected() if either the RCU-protected pointer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) or the RCU-protected data that it points to can change concurrently.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) Like rcu_dereference(), when lockdep is enabled, RCU list and hlist
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) traversal primitives check for being called from within an RCU read-side
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) critical section. However, a lockdep expression can be passed to them
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) as a additional optional argument. With this lockdep expression, these
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) traversal primitives will complain only if the lockdep expression is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) false and they are called from outside any RCU read-side critical section.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) For example, the workqueue for_each_pwq() macro is intended to be used
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) either within an RCU read-side critical section or with wq->mutex held.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) It is thus implemented as follows::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) #define for_each_pwq(pwq, wq)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) list_for_each_entry_rcu((pwq), &(wq)->pwqs, pwqs_node,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) lock_is_held(&(wq->mutex).dep_map))
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags