aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--include/linux/rcupdate.h28
1 files changed, 28 insertions, 0 deletions
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 6a94cc8b1ca0..c56ad15204ec 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -858,6 +858,34 @@ static inline void rcu_read_lock(void)
858/** 858/**
859 * rcu_read_unlock() - marks the end of an RCU read-side critical section. 859 * rcu_read_unlock() - marks the end of an RCU read-side critical section.
860 * 860 *
861 * In most situations, rcu_read_unlock() is immune from deadlock.
862 * However, in kernels built with CONFIG_RCU_BOOST, rcu_read_unlock()
863 * is responsible for deboosting, which it does via rt_mutex_unlock().
864 * Unfortunately, this function acquires the scheduler's runqueue and
865 * priority-inheritance spinlocks. This means that deadlock could result
866 * if the caller of rcu_read_unlock() already holds one of these locks or
867 * any lock that is ever acquired while holding them.
868 *
869 * That said, RCU readers are never priority boosted unless they were
870 * preempted. Therefore, one way to avoid deadlock is to make sure
871 * that preemption never happens within any RCU read-side critical
872 * section whose outermost rcu_read_unlock() is called with one of
873 * rt_mutex_unlock()'s locks held. Such preemption can be avoided in
874 * a number of ways, for example, by invoking preempt_disable() before
875 * critical section's outermost rcu_read_lock().
876 *
877 * Given that the set of locks acquired by rt_mutex_unlock() might change
878 * at any time, a somewhat more future-proofed approach is to make sure
879 * that that preemption never happens within any RCU read-side critical
880 * section whose outermost rcu_read_unlock() is called with irqs disabled.
881 * This approach relies on the fact that rt_mutex_unlock() currently only
882 * acquires irq-disabled locks.
883 *
884 * The second of these two approaches is best in most situations,
885 * however, the first approach can also be useful, at least to those
886 * developers willing to keep abreast of the set of locks acquired by
887 * rt_mutex_unlock().
888 *
861 * See rcu_read_lock() for more information. 889 * See rcu_read_lock() for more information.
862 */ 890 */
863static inline void rcu_read_unlock(void) 891static inline void rcu_read_unlock(void)