summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2018-06-10 18:30:35 +0300
committerLinus Torvalds <torvalds@linux-foundation.org>2018-06-10 18:30:35 +0300
commita8a4021b776b4475e8a4657185a718cdfc07b88c (patch)
tree54a1c6a013247ea164351b156bf1cd8feaeeed56 /include
parent3ca24ce9ff764bc27bceb9b2fd8ece74846c3fd3 (diff)
parent59dc6f3c6d81c0c4379025c4eb56919391d62b67 (diff)
downloadlinux-a8a4021b776b4475e8a4657185a718cdfc07b88c.tar.xz
Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull core fixes from Thomas Gleixner: "A small set of core updates: - Make objtool cope with GCC8 oddities some more - Remove a stale local_irq_save/restore sequence in the signal code along with the stale comment in the RCU code. The underlying issue which led to this has been solved long time ago, but nobody cared to cleanup the hackarounds" * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: signal: Remove no longer required irqsave/restore rcu: Update documentation of rcu_read_unlock() objtool: Fix GCC 8 cold subfunction detection for aliased functions
Diffstat (limited to 'include')
-rw-r--r--include/linux/rcupdate.h4
1 files changed, 1 insertions, 3 deletions
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index e679b175b411..65163aa0bb04 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -652,9 +652,7 @@ static inline void rcu_read_lock(void)
* Unfortunately, this function acquires the scheduler's runqueue and
* priority-inheritance spinlocks. This means that deadlock could result
* if the caller of rcu_read_unlock() already holds one of these locks or
- * any lock that is ever acquired while holding them; or any lock which
- * can be taken from interrupt context because rcu_boost()->rt_mutex_lock()
- * does not disable irqs while taking ->wait_lock.
+ * any lock that is ever acquired while holding them.
*
* That said, RCU readers are never priority boosted unless they were
* preempted. Therefore, one way to avoid deadlock is to make sure