diff options
author | Lai Jiangshan <laijs@cn.fujitsu.com> | 2013-10-30 04:13:22 -0700 |
---|---|---|
committer | Paul E. McKenney <paulmck@linux.vnet.ibm.com> | 2013-12-12 12:34:00 -0800 |
commit | 79a62f957e0b37c59610a96d018cc341aebb48f4 (patch) | |
tree | ade9134ca3e64d87f7debbb102e9d1902763ac6b /crypto/crc32c.c | |
parent | 24ef659a857c3cba40b64ea51ea4fce8d2fb7bbc (diff) | |
download | talos-op-linux-79a62f957e0b37c59610a96d018cc341aebb48f4.tar.gz talos-op-linux-79a62f957e0b37c59610a96d018cc341aebb48f4.zip |
rcu: Warn on allegedly impossible rcu_read_unlock_special() from irq
After commit #10f39bb1b2c1 (rcu: protect __rcu_read_unlock() against
scheduler-using irq handlers), it is no longer possible to enter
the main body of rcu_read_lock_special() from an NMI, interrupt, or
softirq handler. In theory, this implies that the check for "in_irq()
|| in_serving_softirq()" must always fail, so that in theory this check
could be removed entirely.
In practice, this commit wraps this condition with a WARN_ON_ONCE().
If this warning never triggers, then the condition will be removed
entirely.
[ paulmck: And one way of triggering the WARN_ON() is if a scheduling
clock interrupt occurs in an RCU read-side critical section, setting
RCU_READ_UNLOCK_NEED_QS, which is handled by rcu_read_unlock_special().
Updated this commit to return if only that bit was set. ]
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Diffstat (limited to 'crypto/crc32c.c')
0 files changed, 0 insertions, 0 deletions