diff options
author | Paul E. McKenney <paulmck@kernel.org> | 2020-08-06 09:40:18 -0700 |
---|---|---|
committer | Paul E. McKenney <paulmck@kernel.org> | 2020-08-24 18:40:25 -0700 |
commit | f19920e412fdeed1e15691bcee5b40e18b8e96ff (patch) | |
tree | b6618a138268ea1793a5f1c675ac5bc11c814361 /net | |
parent | 29fc5f93320cb447f83baedfe103ed784cadb073 (diff) | |
download | linux-f19920e412fdeed1e15691bcee5b40e18b8e96ff.tar.bz2 |
rcu: Always set .need_qs from __rcu_read_lock() for strict GPs
The ->rcu_read_unlock_special.b.need_qs field in the task_struct
structure indicates that the RCU core needs a quiscent state from the
corresponding task. The __rcu_read_unlock() function checks this (via
an eventual call to rcu_preempt_deferred_qs_irqrestore()), and if set
reports a quiscent state immediately upon exit from the outermost RCU
read-side critical section.
Currently, this flag is only set when the scheduling-clock interrupt
decides that the current RCU grace period is too old, as in about
one full second too old. But if the kernel has been built with
CONFIG_RCU_STRICT_GRACE_PERIOD=y, we clearly do not want to wait that
long. This commit therefore sets the .need_qs field immediately at the
start of the RCU read-side critical section from within __rcu_read_lock()
in order to unconditionally enlist help from __rcu_read_unlock().
But note the additional check for rcu_state.gp_kthread, which prevents
attempts to awaken RCU's grace-period kthread during early boot before
there is a scheduler. Leaving off this check results in early boot hangs.
So early that there is no console output. Thus, this additional check
fails until such time as RCU's grace-period kthread has been created,
avoiding these empty-console hangs.
Reported-by Jann Horn <jannh@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Diffstat (limited to 'net')
0 files changed, 0 insertions, 0 deletions