rcu: Use irq_work to get scheduler's attention in clean context
authorPaul E. McKenney <paulmck@linux.ibm.com>
Thu, 4 Apr 2019 19:19:25 +0000 (12:19 -0700)
committerPaul E. McKenney <paulmck@linux.ibm.com>
Sat, 25 May 2019 21:50:49 +0000 (14:50 -0700)
commit0864f057b050bc6dd68106b3185e02db5140012d
treeccc4c06e416b2a75b0add24d2c69e07b29e52e91
parent385b599e8c04fa843c4d7f785478827cc512d720
rcu: Use irq_work to get scheduler's attention in clean context

When rcu_read_unlock_special() is invoked with interrupts disabled, is
either not in an interrupt handler or is not using RCU_SOFTIRQ, is not
the first RCU read-side critical section in the chain, and either there
is an expedited grace period in flight or this is a NO_HZ_FULL kernel,
the end of the grace period can be unduly delayed.  The reason for this
is that it is not safe to do wakeups in this situation.

This commit fixes this problem by using the irq_work subsystem to
force a later interrupt handler in a clean environment.  Because
set_tsk_need_resched(current) and set_preempt_need_resched() are
invoked prior to this, the scheduler will force a context switch
upon return from this interrupt (though perhaps at the end of any
interrupted preempt-disable or BH-disable region of code), which will
invoke rcu_note_context_switch() (again in a clean environment), which
will in turn give RCU the chance to report the deferred quiescent state.

Of course, by then this task might be within another RCU read-side
critical section.  But that will be detected at that time and reporting
will be further deferred to the outermost rcu_read_unlock().  See
rcu_preempt_need_deferred_qs() and rcu_preempt_deferred_qs() for more
details on the checking.

Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
kernel/rcu/tree.h
kernel/rcu/tree_plugin.h