summaryrefslogtreecommitdiffstats
path: root/kernel/freezer.c
diff options
context:
space:
mode:
authorZqiang <qiang1.zhang@intel.com>2022-04-04 07:59:32 +0800
committerPaul E. McKenney <paulmck@kernel.org>2022-04-20 16:51:11 -0700
commitf596e2ce1c0f250bb3ecc179f611be37e862635f (patch)
treef1757f53792ddda51ed036798280e74eeda820ee /kernel/freezer.c
parentf1efe84d6fd2af163989025bc285ff9b3b0c764f (diff)
downloadlinux-f596e2ce1c0f250bb3ecc179f611be37e862635f.tar.bz2
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 'kernel/freezer.c')
0 files changed, 0 insertions, 0 deletions