diff options
-rw-r--r-- | include/linux/rcupdate.h | 28 |
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 | */ |
863 | static inline void rcu_read_unlock(void) | 891 | static inline void rcu_read_unlock(void) |