diff options
| author |   Zqiang <qiang1.zhang@intel.com> | 2022-04-04 07:59:32 +0800 |
|---|---|---|
| committer |   Paul E. McKenney <paulmck@kernel.org> | 2022-04-20 16:51:11 -0700 |
| commit | f596e2ce1c0f250bb3ecc179f611be37e862635f (patch) | |
| tree | f1757f53792ddda51ed036798280e74eeda820ee /tools/testing/selftests/rcutorture/configs/rcu | |
| parent | rcu_sync: Fix comment to properly reflect rcu_sync_exit() behavior (diff) | |
| download | linux-dev-f596e2ce1c0f250bb3ecc179f611be37e862635f.tar.xz linux-dev-f596e2ce1c0f250bb3ecc179f611be37e862635f.zip | |
rcu: Use IRQ_WORK_INIT_HARD() to avoid rcu_read_unlock() hangs
When booting kernels built with both CONFIG_RCU_STRICT_GRACE_PERIOD=y
and CONFIG_PREEMPT_RT=y, the rcu_read_unlock_special() function's
invocation of irq_work_queue_on() the init_irq_work() causes the
rcu_preempt_deferred_qs_handler() function to work execute in SCHED_FIFO
irq_work kthreads. Because rcu_read_unlock_special() is invoked on each
rcu_read_unlock() in such kernels, the amount of work just keeps piling
up, resulting in a boot-time hang.
This commit therefore avoids this hang by using IRQ_WORK_INIT_HARD()
instead of init_irq_work(), but only in kernels built with both
CONFIG_PREEMPT_RT=y and CONFIG_RCU_STRICT_GRACE_PERIOD=y.
Signed-off-by: Zqiang <qiang1.zhang@intel.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Diffstat (limited to 'tools/testing/selftests/rcutorture/configs/rcu')
0 files changed, 0 insertions, 0 deletions