2019-01-18 02:25:18 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* Read-Copy Update mechanism for mutual exclusion
|
|
|
|
*
|
2008-01-26 04:08:24 +08:00
|
|
|
* Copyright IBM Corporation, 2001
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* Authors: Dipankar Sarma <dipankar@in.ibm.com>
|
|
|
|
* Manfred Spraul <manfred@colorfullife.com>
|
2009-09-19 01:28:19 +08:00
|
|
|
*
|
2019-01-18 02:25:18 +08:00
|
|
|
* Based on the original work by Paul McKenney <paulmck@linux.ibm.com>
|
2005-04-17 06:20:36 +08:00
|
|
|
* and inputs from Rusty Russell, Andrea Arcangeli and Andi Kleen.
|
|
|
|
* Papers:
|
|
|
|
* http://www.rdrop.com/users/paulmck/paper/rclockpdcsproof.pdf
|
|
|
|
* http://lse.sourceforge.net/locking/rclock_OLS.2001.05.01c.sc.pdf (OLS2001)
|
|
|
|
*
|
|
|
|
* For detailed explanation of Read-Copy Update mechanism see -
|
2009-09-19 01:28:19 +08:00
|
|
|
* http://lse.sourceforge.net/locking/rcupdate.html
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
*/
|
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/smp.h>
|
|
|
|
#include <linux/interrupt.h>
|
2017-02-09 01:51:30 +08:00
|
|
|
#include <linux/sched/signal.h>
|
2017-02-09 01:51:35 +08:00
|
|
|
#include <linux/sched/debug.h>
|
2011-07-27 07:09:06 +08:00
|
|
|
#include <linux/atomic.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/bitops.h>
|
|
|
|
#include <linux/percpu.h>
|
|
|
|
#include <linux/notifier.h>
|
|
|
|
#include <linux/cpu.h>
|
2006-03-23 19:00:19 +08:00
|
|
|
#include <linux/mutex.h>
|
2011-05-24 02:51:41 +08:00
|
|
|
#include <linux/export.h>
|
2010-03-16 08:03:43 +08:00
|
|
|
#include <linux/hardirq.h>
|
2012-07-03 05:42:01 +08:00
|
|
|
#include <linux/delay.h>
|
2016-07-16 00:19:41 +08:00
|
|
|
#include <linux/moduleparam.h>
|
2014-06-28 04:42:20 +08:00
|
|
|
#include <linux/kthread.h>
|
2014-08-11 10:47:12 +08:00
|
|
|
#include <linux/tick.h>
|
2017-02-06 16:50:49 +08:00
|
|
|
#include <linux/rcupdate_wait.h>
|
2017-10-27 10:42:28 +08:00
|
|
|
#include <linux/sched/isolation.h>
|
2019-02-13 00:14:37 +08:00
|
|
|
#include <linux/kprobes.h>
|
rcu: Add basic support for kfree_rcu() batching
Recently a discussion about stability and performance of a system
involving a high rate of kfree_rcu() calls surfaced on the list [1]
which led to another discussion how to prepare for this situation.
This patch adds basic batching support for kfree_rcu(). It is "basic"
because we do none of the slab management, dynamic allocation, code
moving or any of the other things, some of which previous attempts did
[2]. These fancier improvements can be follow-up patches and there are
different ideas being discussed in those regards. This is an effort to
start simple, and build up from there. In the future, an extension to
use kfree_bulk and possibly per-slab batching could be done to further
improve performance due to cache-locality and slab-specific bulk free
optimizations. By using an array of pointers, the worker thread
processing the work would need to read lesser data since it does not
need to deal with large rcu_head(s) any longer.
Torture tests follow in the next patch and show improvements of around
5x reduction in number of grace periods on a 16 CPU system. More
details and test data are in that patch.
There is an implication with rcu_barrier() with this patch. Since the
kfree_rcu() calls can be batched, and may not be handed yet to the RCU
machinery in fact, the monitor may not have even run yet to do the
queue_rcu_work(), there seems no easy way of implementing rcu_barrier()
to wait for those kfree_rcu()s that are already made. So this means a
kfree_rcu() followed by an rcu_barrier() does not imply that memory will
be freed once rcu_barrier() returns.
Another implication is higher active memory usage (although not
run-away..) until the kfree_rcu() flooding ends, in comparison to
without batching. More details about this are in the second patch which
adds an rcuperf test.
Finally, in the near future we will get rid of kfree_rcu() special casing
within RCU such as in rcu_do_batch and switch everything to just
batching. Currently we don't do that since timer subsystem is not yet up
and we cannot schedule the kfree_rcu() monitor as the timer subsystem's
lock are not initialized. That would also mean getting rid of
kfree_call_rcu_nobatch() entirely.
[1] http://lore.kernel.org/lkml/20190723035725-mutt-send-email-mst@kernel.org
[2] https://lkml.org/lkml/2017/12/19/824
Cc: kernel-team@android.com
Cc: kernel-team@lge.com
Co-developed-by: Byungchul Park <byungchul.park@lge.com>
Signed-off-by: Byungchul Park <byungchul.park@lge.com>
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
[ paulmck: Applied 0day and Paul Walmsley feedback on ->monitor_todo. ]
[ paulmck: Make it work during early boot. ]
[ paulmck: Add a crude early boot self-test. ]
[ paulmck: Style adjustments and experimental docbook structure header. ]
Link: https://lore.kernel.org/lkml/alpine.DEB.2.21.9999.1908161931110.32497@viisi.sifive.com/T/#me9956f66cb611b95d26ae92700e1d901f46e8c59
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2019-08-06 06:22:27 +08:00
|
|
|
#include <linux/slab.h>
|
2020-03-21 05:29:08 +08:00
|
|
|
#include <linux/irq_work.h>
|
2020-05-29 10:33:47 +08:00
|
|
|
#include <linux/rcupdate_trace.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2011-06-18 06:53:19 +08:00
|
|
|
#define CREATE_TRACE_POINTS
|
|
|
|
|
|
|
|
#include "rcu.h"
|
|
|
|
|
2013-10-09 11:23:47 +08:00
|
|
|
#ifdef MODULE_PARAM_PREFIX
|
|
|
|
#undef MODULE_PARAM_PREFIX
|
|
|
|
#endif
|
|
|
|
#define MODULE_PARAM_PREFIX "rcupdate."
|
|
|
|
|
2020-04-15 01:19:02 +08:00
|
|
|
#ifndef data_race
|
|
|
|
#define data_race(expr) \
|
|
|
|
({ \
|
|
|
|
expr; \
|
|
|
|
})
|
|
|
|
#endif
|
|
|
|
#ifndef ASSERT_EXCLUSIVE_WRITER
|
|
|
|
#define ASSERT_EXCLUSIVE_WRITER(var) do { } while (0)
|
|
|
|
#endif
|
|
|
|
#ifndef ASSERT_EXCLUSIVE_ACCESS
|
|
|
|
#define ASSERT_EXCLUSIVE_ACCESS(var) do { } while (0)
|
|
|
|
#endif
|
|
|
|
|
2015-12-08 05:09:52 +08:00
|
|
|
#ifndef CONFIG_TINY_RCU
|
2012-10-05 14:59:15 +08:00
|
|
|
module_param(rcu_expedited, int, 0);
|
2015-11-25 07:44:06 +08:00
|
|
|
module_param(rcu_normal, int, 0);
|
2015-11-26 10:56:00 +08:00
|
|
|
static int rcu_normal_after_boot;
|
|
|
|
module_param(rcu_normal_after_boot, int, 0);
|
2015-12-08 05:09:52 +08:00
|
|
|
#endif /* #ifndef CONFIG_TINY_RCU */
|
2015-11-26 10:56:00 +08:00
|
|
|
|
2016-03-23 23:11:48 +08:00
|
|
|
#ifdef CONFIG_DEBUG_LOCK_ALLOC
|
2015-05-26 23:48:34 +08:00
|
|
|
/**
|
2019-07-17 06:12:22 +08:00
|
|
|
* rcu_read_lock_held_common() - might we be in RCU-sched read-side critical section?
|
|
|
|
* @ret: Best guess answer if lockdep cannot be relied on
|
2015-05-26 23:48:34 +08:00
|
|
|
*
|
2020-03-17 22:54:18 +08:00
|
|
|
* Returns true if lockdep must be ignored, in which case ``*ret`` contains
|
2019-07-17 06:12:22 +08:00
|
|
|
* the best guess described below. Otherwise returns false, in which
|
2020-03-17 22:54:18 +08:00
|
|
|
* case ``*ret`` tells the caller nothing and the caller should instead
|
2019-07-17 06:12:22 +08:00
|
|
|
* consult lockdep.
|
|
|
|
*
|
2020-03-17 22:54:18 +08:00
|
|
|
* If CONFIG_DEBUG_LOCK_ALLOC is selected, set ``*ret`` to nonzero iff in an
|
2015-05-26 23:48:34 +08:00
|
|
|
* RCU-sched read-side critical section. In absence of
|
|
|
|
* CONFIG_DEBUG_LOCK_ALLOC, this assumes we are in an RCU-sched read-side
|
|
|
|
* critical section unless it can prove otherwise. Note that disabling
|
|
|
|
* of preemption (including disabling irqs) counts as an RCU-sched
|
|
|
|
* read-side critical section. This is useful for debug checks in functions
|
|
|
|
* that required that they be called within an RCU-sched read-side
|
|
|
|
* critical section.
|
|
|
|
*
|
|
|
|
* Check debug_lockdep_rcu_enabled() to prevent false positives during boot
|
|
|
|
* and while lockdep is disabled.
|
|
|
|
*
|
2019-07-17 06:12:22 +08:00
|
|
|
* Note that if the CPU is in the idle loop from an RCU point of view (ie:
|
|
|
|
* that we are in the section between rcu_idle_enter() and rcu_idle_exit())
|
2020-03-17 22:54:18 +08:00
|
|
|
* then rcu_read_lock_held() sets ``*ret`` to false even if the CPU did an
|
2019-07-17 06:12:22 +08:00
|
|
|
* rcu_read_lock(). The reason for this is that RCU ignores CPUs that are
|
|
|
|
* in such a section, considering these as in extended quiescent state,
|
|
|
|
* so such a CPU is effectively never in an RCU read-side critical section
|
|
|
|
* regardless of what RCU primitives it invokes. This state of affairs is
|
|
|
|
* required --- we need to keep an RCU-free window in idle where the CPU may
|
|
|
|
* possibly enter into low power mode. This way we can notice an extended
|
|
|
|
* quiescent state to other CPUs that started a grace period. Otherwise
|
|
|
|
* we would delay any grace period as long as we run in the idle task.
|
2015-05-26 23:48:34 +08:00
|
|
|
*
|
2019-07-17 06:12:22 +08:00
|
|
|
* Similarly, we avoid claiming an RCU read lock held if the current
|
2015-05-26 23:48:34 +08:00
|
|
|
* CPU is offline.
|
|
|
|
*/
|
2019-07-17 06:12:22 +08:00
|
|
|
static bool rcu_read_lock_held_common(bool *ret)
|
|
|
|
{
|
|
|
|
if (!debug_lockdep_rcu_enabled()) {
|
2020-03-28 05:23:53 +08:00
|
|
|
*ret = true;
|
2019-07-17 06:12:22 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (!rcu_is_watching()) {
|
2020-03-28 05:23:53 +08:00
|
|
|
*ret = false;
|
2019-07-17 06:12:22 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (!rcu_lockdep_current_cpu_online()) {
|
2020-03-28 05:23:53 +08:00
|
|
|
*ret = false;
|
2019-07-17 06:12:22 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-05-26 23:48:34 +08:00
|
|
|
int rcu_read_lock_sched_held(void)
|
|
|
|
{
|
2019-07-17 06:12:22 +08:00
|
|
|
bool ret;
|
2015-05-26 23:48:34 +08:00
|
|
|
|
2019-07-17 06:12:22 +08:00
|
|
|
if (rcu_read_lock_held_common(&ret))
|
|
|
|
return ret;
|
2019-07-17 06:12:21 +08:00
|
|
|
return lock_is_held(&rcu_sched_lock_map) || !preemptible();
|
2015-05-26 23:48:34 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(rcu_read_lock_sched_held);
|
|
|
|
#endif
|
|
|
|
|
2015-02-19 04:24:30 +08:00
|
|
|
#ifndef CONFIG_TINY_RCU
|
|
|
|
|
2015-11-25 07:44:06 +08:00
|
|
|
/*
|
|
|
|
* Should expedited grace-period primitives always fall back to their
|
|
|
|
* non-expedited counterparts? Intended for use within RCU. Note
|
|
|
|
* that if the user specifies both rcu_expedited and rcu_normal, then
|
rcu: Narrow early boot window of illegal synchronous grace periods
The current preemptible RCU implementation goes through three phases
during bootup. In the first phase, there is only one CPU that is running
with preemption disabled, so that a no-op is a synchronous grace period.
In the second mid-boot phase, the scheduler is running, but RCU has
not yet gotten its kthreads spawned (and, for expedited grace periods,
workqueues are not yet running. During this time, any attempt to do
a synchronous grace period will hang the system (or complain bitterly,
depending). In the third and final phase, RCU is fully operational and
everything works normally.
This has been OK for some time, but there has recently been some
synchronous grace periods showing up during the second mid-boot phase.
This code worked "by accident" for awhile, but started failing as soon
as expedited RCU grace periods switched over to workqueues in commit
8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue").
Note that the code was buggy even before this commit, as it was subject
to failure on real-time systems that forced all expedited grace periods
to run as normal grace periods (for example, using the rcu_normal ksysfs
parameter). The callchain from the failure case is as follows:
early_amd_iommu_init()
|-> acpi_put_table(ivrs_base);
|-> acpi_tb_put_table(table_desc);
|-> acpi_tb_invalidate_table(table_desc);
|-> acpi_tb_release_table(...)
|-> acpi_os_unmap_memory
|-> acpi_os_unmap_iomem
|-> acpi_os_map_cleanup
|-> synchronize_rcu_expedited
The kernel showing this callchain was built with CONFIG_PREEMPT_RCU=y,
which caused the code to try using workqueues before they were
initialized, which did not go well.
This commit therefore reworks RCU to permit synchronous grace periods
to proceed during this mid-boot phase. This commit is therefore a
fix to a regression introduced in v4.9, and is therefore being put
forward post-merge-window in v4.10.
This commit sets a flag from the existing rcu_scheduler_starting()
function which causes all synchronous grace periods to take the expedited
path. The expedited path now checks this flag, using the requesting task
to drive the expedited grace period forward during the mid-boot phase.
Finally, this flag is updated by a core_initcall() function named
rcu_exp_runtime_mode(), which causes the runtime codepaths to be used.
Note that this arrangement assumes that tasks are not sent POSIX signals
(or anything similar) from the time that the first task is spawned
through core_initcall() time.
Fixes: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
Reported-by: "Zheng, Lv" <lv.zheng@intel.com>
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Stan Kain <stan.kain@gmail.com>
Tested-by: Ivan <waffolz@hotmail.com>
Tested-by: Emanuel Castelo <emanuel.castelo@gmail.com>
Tested-by: Bruno Pesavento <bpesavento@infinito.it>
Tested-by: Borislav Petkov <bp@suse.de>
Tested-by: Frederic Bezies <fredbezies@gmail.com>
Cc: <stable@vger.kernel.org> # 4.9.0-
2017-01-10 18:28:26 +08:00
|
|
|
* rcu_normal wins. (Except during the time period during boot from
|
2017-02-11 06:32:54 +08:00
|
|
|
* when the first task is spawned until the rcu_set_runtime_mode()
|
rcu: Narrow early boot window of illegal synchronous grace periods
The current preemptible RCU implementation goes through three phases
during bootup. In the first phase, there is only one CPU that is running
with preemption disabled, so that a no-op is a synchronous grace period.
In the second mid-boot phase, the scheduler is running, but RCU has
not yet gotten its kthreads spawned (and, for expedited grace periods,
workqueues are not yet running. During this time, any attempt to do
a synchronous grace period will hang the system (or complain bitterly,
depending). In the third and final phase, RCU is fully operational and
everything works normally.
This has been OK for some time, but there has recently been some
synchronous grace periods showing up during the second mid-boot phase.
This code worked "by accident" for awhile, but started failing as soon
as expedited RCU grace periods switched over to workqueues in commit
8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue").
Note that the code was buggy even before this commit, as it was subject
to failure on real-time systems that forced all expedited grace periods
to run as normal grace periods (for example, using the rcu_normal ksysfs
parameter). The callchain from the failure case is as follows:
early_amd_iommu_init()
|-> acpi_put_table(ivrs_base);
|-> acpi_tb_put_table(table_desc);
|-> acpi_tb_invalidate_table(table_desc);
|-> acpi_tb_release_table(...)
|-> acpi_os_unmap_memory
|-> acpi_os_unmap_iomem
|-> acpi_os_map_cleanup
|-> synchronize_rcu_expedited
The kernel showing this callchain was built with CONFIG_PREEMPT_RCU=y,
which caused the code to try using workqueues before they were
initialized, which did not go well.
This commit therefore reworks RCU to permit synchronous grace periods
to proceed during this mid-boot phase. This commit is therefore a
fix to a regression introduced in v4.9, and is therefore being put
forward post-merge-window in v4.10.
This commit sets a flag from the existing rcu_scheduler_starting()
function which causes all synchronous grace periods to take the expedited
path. The expedited path now checks this flag, using the requesting task
to drive the expedited grace period forward during the mid-boot phase.
Finally, this flag is updated by a core_initcall() function named
rcu_exp_runtime_mode(), which causes the runtime codepaths to be used.
Note that this arrangement assumes that tasks are not sent POSIX signals
(or anything similar) from the time that the first task is spawned
through core_initcall() time.
Fixes: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
Reported-by: "Zheng, Lv" <lv.zheng@intel.com>
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Stan Kain <stan.kain@gmail.com>
Tested-by: Ivan <waffolz@hotmail.com>
Tested-by: Emanuel Castelo <emanuel.castelo@gmail.com>
Tested-by: Bruno Pesavento <bpesavento@infinito.it>
Tested-by: Borislav Petkov <bp@suse.de>
Tested-by: Frederic Bezies <fredbezies@gmail.com>
Cc: <stable@vger.kernel.org> # 4.9.0-
2017-01-10 18:28:26 +08:00
|
|
|
* core_initcall() is invoked, at which point everything is expedited.)
|
2015-11-25 07:44:06 +08:00
|
|
|
*/
|
|
|
|
bool rcu_gp_is_normal(void)
|
|
|
|
{
|
rcu: Narrow early boot window of illegal synchronous grace periods
The current preemptible RCU implementation goes through three phases
during bootup. In the first phase, there is only one CPU that is running
with preemption disabled, so that a no-op is a synchronous grace period.
In the second mid-boot phase, the scheduler is running, but RCU has
not yet gotten its kthreads spawned (and, for expedited grace periods,
workqueues are not yet running. During this time, any attempt to do
a synchronous grace period will hang the system (or complain bitterly,
depending). In the third and final phase, RCU is fully operational and
everything works normally.
This has been OK for some time, but there has recently been some
synchronous grace periods showing up during the second mid-boot phase.
This code worked "by accident" for awhile, but started failing as soon
as expedited RCU grace periods switched over to workqueues in commit
8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue").
Note that the code was buggy even before this commit, as it was subject
to failure on real-time systems that forced all expedited grace periods
to run as normal grace periods (for example, using the rcu_normal ksysfs
parameter). The callchain from the failure case is as follows:
early_amd_iommu_init()
|-> acpi_put_table(ivrs_base);
|-> acpi_tb_put_table(table_desc);
|-> acpi_tb_invalidate_table(table_desc);
|-> acpi_tb_release_table(...)
|-> acpi_os_unmap_memory
|-> acpi_os_unmap_iomem
|-> acpi_os_map_cleanup
|-> synchronize_rcu_expedited
The kernel showing this callchain was built with CONFIG_PREEMPT_RCU=y,
which caused the code to try using workqueues before they were
initialized, which did not go well.
This commit therefore reworks RCU to permit synchronous grace periods
to proceed during this mid-boot phase. This commit is therefore a
fix to a regression introduced in v4.9, and is therefore being put
forward post-merge-window in v4.10.
This commit sets a flag from the existing rcu_scheduler_starting()
function which causes all synchronous grace periods to take the expedited
path. The expedited path now checks this flag, using the requesting task
to drive the expedited grace period forward during the mid-boot phase.
Finally, this flag is updated by a core_initcall() function named
rcu_exp_runtime_mode(), which causes the runtime codepaths to be used.
Note that this arrangement assumes that tasks are not sent POSIX signals
(or anything similar) from the time that the first task is spawned
through core_initcall() time.
Fixes: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
Reported-by: "Zheng, Lv" <lv.zheng@intel.com>
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Stan Kain <stan.kain@gmail.com>
Tested-by: Ivan <waffolz@hotmail.com>
Tested-by: Emanuel Castelo <emanuel.castelo@gmail.com>
Tested-by: Bruno Pesavento <bpesavento@infinito.it>
Tested-by: Borislav Petkov <bp@suse.de>
Tested-by: Frederic Bezies <fredbezies@gmail.com>
Cc: <stable@vger.kernel.org> # 4.9.0-
2017-01-10 18:28:26 +08:00
|
|
|
return READ_ONCE(rcu_normal) &&
|
|
|
|
rcu_scheduler_active != RCU_SCHEDULER_INIT;
|
2015-11-25 07:44:06 +08:00
|
|
|
}
|
2016-01-02 05:38:12 +08:00
|
|
|
EXPORT_SYMBOL_GPL(rcu_gp_is_normal);
|
2015-11-25 07:44:06 +08:00
|
|
|
|
2016-11-03 00:30:02 +08:00
|
|
|
static atomic_t rcu_expedited_nesting = ATOMIC_INIT(1);
|
2015-02-19 04:24:30 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Should normal grace-period primitives be expedited? Intended for
|
|
|
|
* use within RCU. Note that this function takes the rcu_expedited
|
rcu: Narrow early boot window of illegal synchronous grace periods
The current preemptible RCU implementation goes through three phases
during bootup. In the first phase, there is only one CPU that is running
with preemption disabled, so that a no-op is a synchronous grace period.
In the second mid-boot phase, the scheduler is running, but RCU has
not yet gotten its kthreads spawned (and, for expedited grace periods,
workqueues are not yet running. During this time, any attempt to do
a synchronous grace period will hang the system (or complain bitterly,
depending). In the third and final phase, RCU is fully operational and
everything works normally.
This has been OK for some time, but there has recently been some
synchronous grace periods showing up during the second mid-boot phase.
This code worked "by accident" for awhile, but started failing as soon
as expedited RCU grace periods switched over to workqueues in commit
8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue").
Note that the code was buggy even before this commit, as it was subject
to failure on real-time systems that forced all expedited grace periods
to run as normal grace periods (for example, using the rcu_normal ksysfs
parameter). The callchain from the failure case is as follows:
early_amd_iommu_init()
|-> acpi_put_table(ivrs_base);
|-> acpi_tb_put_table(table_desc);
|-> acpi_tb_invalidate_table(table_desc);
|-> acpi_tb_release_table(...)
|-> acpi_os_unmap_memory
|-> acpi_os_unmap_iomem
|-> acpi_os_map_cleanup
|-> synchronize_rcu_expedited
The kernel showing this callchain was built with CONFIG_PREEMPT_RCU=y,
which caused the code to try using workqueues before they were
initialized, which did not go well.
This commit therefore reworks RCU to permit synchronous grace periods
to proceed during this mid-boot phase. This commit is therefore a
fix to a regression introduced in v4.9, and is therefore being put
forward post-merge-window in v4.10.
This commit sets a flag from the existing rcu_scheduler_starting()
function which causes all synchronous grace periods to take the expedited
path. The expedited path now checks this flag, using the requesting task
to drive the expedited grace period forward during the mid-boot phase.
Finally, this flag is updated by a core_initcall() function named
rcu_exp_runtime_mode(), which causes the runtime codepaths to be used.
Note that this arrangement assumes that tasks are not sent POSIX signals
(or anything similar) from the time that the first task is spawned
through core_initcall() time.
Fixes: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
Reported-by: "Zheng, Lv" <lv.zheng@intel.com>
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Stan Kain <stan.kain@gmail.com>
Tested-by: Ivan <waffolz@hotmail.com>
Tested-by: Emanuel Castelo <emanuel.castelo@gmail.com>
Tested-by: Bruno Pesavento <bpesavento@infinito.it>
Tested-by: Borislav Petkov <bp@suse.de>
Tested-by: Frederic Bezies <fredbezies@gmail.com>
Cc: <stable@vger.kernel.org> # 4.9.0-
2017-01-10 18:28:26 +08:00
|
|
|
* sysfs/boot variable and rcu_scheduler_active into account as well
|
|
|
|
* as the rcu_expedite_gp() nesting. So looping on rcu_unexpedite_gp()
|
|
|
|
* until rcu_gp_is_expedited() returns false is a -really- bad idea.
|
2015-02-19 04:24:30 +08:00
|
|
|
*/
|
|
|
|
bool rcu_gp_is_expedited(void)
|
|
|
|
{
|
2019-07-05 23:05:10 +08:00
|
|
|
return rcu_expedited || atomic_read(&rcu_expedited_nesting);
|
2015-02-19 04:24:30 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(rcu_gp_is_expedited);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* rcu_expedite_gp - Expedite future RCU grace periods
|
|
|
|
*
|
|
|
|
* After a call to this function, future calls to synchronize_rcu() and
|
|
|
|
* friends act as the corresponding synchronize_rcu_expedited() function
|
|
|
|
* had instead been called.
|
|
|
|
*/
|
|
|
|
void rcu_expedite_gp(void)
|
|
|
|
{
|
|
|
|
atomic_inc(&rcu_expedited_nesting);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(rcu_expedite_gp);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* rcu_unexpedite_gp - Cancel prior rcu_expedite_gp() invocation
|
|
|
|
*
|
|
|
|
* Undo a prior call to rcu_expedite_gp(). If all prior calls to
|
|
|
|
* rcu_expedite_gp() are undone by a subsequent call to rcu_unexpedite_gp(),
|
|
|
|
* and if the rcu_expedited sysfs/boot parameter is not set, then all
|
|
|
|
* subsequent calls to synchronize_rcu() and friends will return to
|
|
|
|
* their normal non-expedited behavior.
|
|
|
|
*/
|
|
|
|
void rcu_unexpedite_gp(void)
|
|
|
|
{
|
|
|
|
atomic_dec(&rcu_expedited_nesting);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(rcu_unexpedite_gp);
|
|
|
|
|
2019-11-29 10:54:06 +08:00
|
|
|
static bool rcu_boot_ended __read_mostly;
|
|
|
|
|
2015-02-20 02:51:32 +08:00
|
|
|
/*
|
|
|
|
* Inform RCU of the end of the in-kernel boot sequence.
|
|
|
|
*/
|
|
|
|
void rcu_end_inkernel_boot(void)
|
|
|
|
{
|
2016-11-03 00:30:02 +08:00
|
|
|
rcu_unexpedite_gp();
|
2015-11-26 10:56:00 +08:00
|
|
|
if (rcu_normal_after_boot)
|
|
|
|
WRITE_ONCE(rcu_normal, 1);
|
2020-06-02 02:45:49 +08:00
|
|
|
rcu_boot_ended = true;
|
2015-02-20 02:51:32 +08:00
|
|
|
}
|
2015-02-19 04:24:30 +08:00
|
|
|
|
2019-11-29 10:54:06 +08:00
|
|
|
/*
|
|
|
|
* Let rcutorture know when it is OK to turn it up to eleven.
|
|
|
|
*/
|
|
|
|
bool rcu_inkernel_boot_has_ended(void)
|
|
|
|
{
|
|
|
|
return rcu_boot_ended;
|
2015-02-20 02:51:32 +08:00
|
|
|
}
|
2019-11-29 10:54:06 +08:00
|
|
|
EXPORT_SYMBOL_GPL(rcu_inkernel_boot_has_ended);
|
2015-02-19 04:24:30 +08:00
|
|
|
|
2015-12-08 05:09:52 +08:00
|
|
|
#endif /* #ifndef CONFIG_TINY_RCU */
|
|
|
|
|
2017-02-11 06:32:54 +08:00
|
|
|
/*
|
|
|
|
* Test each non-SRCU synchronous grace-period wait API. This is
|
|
|
|
* useful just after a change in mode for these primitives, and
|
|
|
|
* during early boot.
|
|
|
|
*/
|
|
|
|
void rcu_test_sync_prims(void)
|
|
|
|
{
|
|
|
|
if (!IS_ENABLED(CONFIG_PROVE_RCU))
|
|
|
|
return;
|
|
|
|
synchronize_rcu();
|
|
|
|
synchronize_rcu_expedited();
|
|
|
|
}
|
|
|
|
|
|
|
|
#if !defined(CONFIG_TINY_RCU) || defined(CONFIG_SRCU)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Switch to run-time mode once RCU has fully initialized.
|
|
|
|
*/
|
|
|
|
static int __init rcu_set_runtime_mode(void)
|
|
|
|
{
|
|
|
|
rcu_test_sync_prims();
|
|
|
|
rcu_scheduler_active = RCU_SCHEDULER_RUNNING;
|
rcu: Add basic support for kfree_rcu() batching
Recently a discussion about stability and performance of a system
involving a high rate of kfree_rcu() calls surfaced on the list [1]
which led to another discussion how to prepare for this situation.
This patch adds basic batching support for kfree_rcu(). It is "basic"
because we do none of the slab management, dynamic allocation, code
moving or any of the other things, some of which previous attempts did
[2]. These fancier improvements can be follow-up patches and there are
different ideas being discussed in those regards. This is an effort to
start simple, and build up from there. In the future, an extension to
use kfree_bulk and possibly per-slab batching could be done to further
improve performance due to cache-locality and slab-specific bulk free
optimizations. By using an array of pointers, the worker thread
processing the work would need to read lesser data since it does not
need to deal with large rcu_head(s) any longer.
Torture tests follow in the next patch and show improvements of around
5x reduction in number of grace periods on a 16 CPU system. More
details and test data are in that patch.
There is an implication with rcu_barrier() with this patch. Since the
kfree_rcu() calls can be batched, and may not be handed yet to the RCU
machinery in fact, the monitor may not have even run yet to do the
queue_rcu_work(), there seems no easy way of implementing rcu_barrier()
to wait for those kfree_rcu()s that are already made. So this means a
kfree_rcu() followed by an rcu_barrier() does not imply that memory will
be freed once rcu_barrier() returns.
Another implication is higher active memory usage (although not
run-away..) until the kfree_rcu() flooding ends, in comparison to
without batching. More details about this are in the second patch which
adds an rcuperf test.
Finally, in the near future we will get rid of kfree_rcu() special casing
within RCU such as in rcu_do_batch and switch everything to just
batching. Currently we don't do that since timer subsystem is not yet up
and we cannot schedule the kfree_rcu() monitor as the timer subsystem's
lock are not initialized. That would also mean getting rid of
kfree_call_rcu_nobatch() entirely.
[1] http://lore.kernel.org/lkml/20190723035725-mutt-send-email-mst@kernel.org
[2] https://lkml.org/lkml/2017/12/19/824
Cc: kernel-team@android.com
Cc: kernel-team@lge.com
Co-developed-by: Byungchul Park <byungchul.park@lge.com>
Signed-off-by: Byungchul Park <byungchul.park@lge.com>
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
[ paulmck: Applied 0day and Paul Walmsley feedback on ->monitor_todo. ]
[ paulmck: Make it work during early boot. ]
[ paulmck: Add a crude early boot self-test. ]
[ paulmck: Style adjustments and experimental docbook structure header. ]
Link: https://lore.kernel.org/lkml/alpine.DEB.2.21.9999.1908161931110.32497@viisi.sifive.com/T/#me9956f66cb611b95d26ae92700e1d901f46e8c59
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2019-08-06 06:22:27 +08:00
|
|
|
kfree_rcu_scheduler_running();
|
2017-02-11 06:32:54 +08:00
|
|
|
rcu_test_sync_prims();
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
core_initcall(rcu_set_runtime_mode);
|
|
|
|
|
|
|
|
#endif /* #if !defined(CONFIG_TINY_RCU) || defined(CONFIG_SRCU) */
|
|
|
|
|
2009-09-24 07:18:13 +08:00
|
|
|
#ifdef CONFIG_DEBUG_LOCK_ALLOC
|
|
|
|
static struct lock_class_key rcu_lock_key;
|
lockdep: Introduce wait-type checks
Extend lockdep to validate lock wait-type context.
The current wait-types are:
LD_WAIT_FREE, /* wait free, rcu etc.. */
LD_WAIT_SPIN, /* spin loops, raw_spinlock_t etc.. */
LD_WAIT_CONFIG, /* CONFIG_PREEMPT_LOCK, spinlock_t etc.. */
LD_WAIT_SLEEP, /* sleeping locks, mutex_t etc.. */
Where lockdep validates that the current lock (the one being acquired)
fits in the current wait-context (as generated by the held stack).
This ensures that there is no attempt to acquire mutexes while holding
spinlocks, to acquire spinlocks while holding raw_spinlocks and so on. In
other words, its a more fancy might_sleep().
Obviously RCU made the entire ordeal more complex than a simple single
value test because RCU can be acquired in (pretty much) any context and
while it presents a context to nested locks it is not the same as it
got acquired in.
Therefore its necessary to split the wait_type into two values, one
representing the acquire (outer) and one representing the nested context
(inner). For most 'normal' locks these two are the same.
[ To make static initialization easier we have the rule that:
.outer == INV means .outer == .inner; because INV == 0. ]
It further means that its required to find the minimal .inner of the held
stack to compare against the outer of the new lock; because while 'normal'
RCU presents a CONFIG type to nested locks, if it is taken while already
holding a SPIN type it obviously doesn't relax the rules.
Below is an example output generated by the trivial test code:
raw_spin_lock(&foo);
spin_lock(&bar);
spin_unlock(&bar);
raw_spin_unlock(&foo);
[ BUG: Invalid wait context ]
-----------------------------
swapper/0/1 is trying to lock:
ffffc90000013f20 (&bar){....}-{3:3}, at: kernel_init+0xdb/0x187
other info that might help us debug this:
1 lock held by swapper/0/1:
#0: ffffc90000013ee0 (&foo){+.+.}-{2:2}, at: kernel_init+0xd1/0x187
The way to read it is to look at the new -{n,m} part in the lock
description; -{3:3} for the attempted lock, and try and match that up to
the held locks, which in this case is the one: -{2,2}.
This tells that the acquiring lock requires a more relaxed environment than
presented by the lock stack.
Currently only the normal locks and RCU are converted, the rest of the
lockdep users defaults to .inner = INV which is ignored. More conversions
can be done when desired.
The check for spinlock_t nesting is not enabled by default. It's a separate
config option for now as there are known problems which are currently
addressed. The config option allows to identify these problems and to
verify that the solutions found are indeed solving them.
The config switch will be removed and the checks will permanently enabled
once the vast majority of issues has been addressed.
[ bigeasy: Move LD_WAIT_FREE,… out of CONFIG_LOCKDEP to avoid compile
failure with CONFIG_DEBUG_SPINLOCK + !CONFIG_LOCKDEP]
[ tglx: Add the config option ]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200321113242.427089655@linutronix.de
2020-03-21 19:26:01 +08:00
|
|
|
struct lockdep_map rcu_lock_map = {
|
|
|
|
.name = "rcu_read_lock",
|
|
|
|
.key = &rcu_lock_key,
|
|
|
|
.wait_type_outer = LD_WAIT_FREE,
|
|
|
|
.wait_type_inner = LD_WAIT_CONFIG, /* XXX PREEMPT_RCU ? */
|
|
|
|
};
|
2009-09-24 07:18:13 +08:00
|
|
|
EXPORT_SYMBOL_GPL(rcu_lock_map);
|
rcu: Introduce lockdep-based checking to RCU read-side primitives
Inspection is proving insufficient to catch all RCU misuses,
which is understandable given that rcu_dereference() might be
protected by any of four different flavors of RCU (RCU, RCU-bh,
RCU-sched, and SRCU), and might also/instead be protected by any
of a number of locking primitives. It is therefore time to
enlist the aid of lockdep.
This set of patches is inspired by earlier work by Peter
Zijlstra and Thomas Gleixner, and takes the following approach:
o Set up separate lockdep classes for RCU, RCU-bh, and RCU-sched.
o Set up separate lockdep classes for each instance of SRCU.
o Create primitives that check for being in an RCU read-side
critical section. These return exact answers if lockdep is
fully enabled, but if unsure, report being in an RCU read-side
critical section. (We want to avoid false positives!)
The primitives are:
For RCU: rcu_read_lock_held(void)
For RCU-bh: rcu_read_lock_bh_held(void)
For RCU-sched: rcu_read_lock_sched_held(void)
For SRCU: srcu_read_lock_held(struct srcu_struct *sp)
o Add rcu_dereference_check(), which takes a second argument
in which one places a boolean expression based on the above
primitives and/or lockdep_is_held().
o A new kernel configuration parameter, CONFIG_PROVE_RCU, enables
rcu_dereference_check(). This depends on CONFIG_PROVE_LOCKING,
and should be quite helpful during the transition period while
CONFIG_PROVE_RCU-unaware patches are in flight.
The existing rcu_dereference() primitive does no checking, but
upcoming patches will change that.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: laijs@cn.fujitsu.com
Cc: dipankar@in.ibm.com
Cc: mathieu.desnoyers@polymtl.ca
Cc: josh@joshtriplett.org
Cc: dvhltc@us.ibm.com
Cc: niv@us.ibm.com
Cc: peterz@infradead.org
Cc: rostedt@goodmis.org
Cc: Valdis.Kletnieks@vt.edu
Cc: dhowells@redhat.com
LKML-Reference: <1266887105-1528-1-git-send-email-paulmck@linux.vnet.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-02-23 09:04:45 +08:00
|
|
|
|
|
|
|
static struct lock_class_key rcu_bh_lock_key;
|
lockdep: Introduce wait-type checks
Extend lockdep to validate lock wait-type context.
The current wait-types are:
LD_WAIT_FREE, /* wait free, rcu etc.. */
LD_WAIT_SPIN, /* spin loops, raw_spinlock_t etc.. */
LD_WAIT_CONFIG, /* CONFIG_PREEMPT_LOCK, spinlock_t etc.. */
LD_WAIT_SLEEP, /* sleeping locks, mutex_t etc.. */
Where lockdep validates that the current lock (the one being acquired)
fits in the current wait-context (as generated by the held stack).
This ensures that there is no attempt to acquire mutexes while holding
spinlocks, to acquire spinlocks while holding raw_spinlocks and so on. In
other words, its a more fancy might_sleep().
Obviously RCU made the entire ordeal more complex than a simple single
value test because RCU can be acquired in (pretty much) any context and
while it presents a context to nested locks it is not the same as it
got acquired in.
Therefore its necessary to split the wait_type into two values, one
representing the acquire (outer) and one representing the nested context
(inner). For most 'normal' locks these two are the same.
[ To make static initialization easier we have the rule that:
.outer == INV means .outer == .inner; because INV == 0. ]
It further means that its required to find the minimal .inner of the held
stack to compare against the outer of the new lock; because while 'normal'
RCU presents a CONFIG type to nested locks, if it is taken while already
holding a SPIN type it obviously doesn't relax the rules.
Below is an example output generated by the trivial test code:
raw_spin_lock(&foo);
spin_lock(&bar);
spin_unlock(&bar);
raw_spin_unlock(&foo);
[ BUG: Invalid wait context ]
-----------------------------
swapper/0/1 is trying to lock:
ffffc90000013f20 (&bar){....}-{3:3}, at: kernel_init+0xdb/0x187
other info that might help us debug this:
1 lock held by swapper/0/1:
#0: ffffc90000013ee0 (&foo){+.+.}-{2:2}, at: kernel_init+0xd1/0x187
The way to read it is to look at the new -{n,m} part in the lock
description; -{3:3} for the attempted lock, and try and match that up to
the held locks, which in this case is the one: -{2,2}.
This tells that the acquiring lock requires a more relaxed environment than
presented by the lock stack.
Currently only the normal locks and RCU are converted, the rest of the
lockdep users defaults to .inner = INV which is ignored. More conversions
can be done when desired.
The check for spinlock_t nesting is not enabled by default. It's a separate
config option for now as there are known problems which are currently
addressed. The config option allows to identify these problems and to
verify that the solutions found are indeed solving them.
The config switch will be removed and the checks will permanently enabled
once the vast majority of issues has been addressed.
[ bigeasy: Move LD_WAIT_FREE,… out of CONFIG_LOCKDEP to avoid compile
failure with CONFIG_DEBUG_SPINLOCK + !CONFIG_LOCKDEP]
[ tglx: Add the config option ]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200321113242.427089655@linutronix.de
2020-03-21 19:26:01 +08:00
|
|
|
struct lockdep_map rcu_bh_lock_map = {
|
|
|
|
.name = "rcu_read_lock_bh",
|
|
|
|
.key = &rcu_bh_lock_key,
|
|
|
|
.wait_type_outer = LD_WAIT_FREE,
|
|
|
|
.wait_type_inner = LD_WAIT_CONFIG, /* PREEMPT_LOCK also makes BH preemptible */
|
|
|
|
};
|
rcu: Introduce lockdep-based checking to RCU read-side primitives
Inspection is proving insufficient to catch all RCU misuses,
which is understandable given that rcu_dereference() might be
protected by any of four different flavors of RCU (RCU, RCU-bh,
RCU-sched, and SRCU), and might also/instead be protected by any
of a number of locking primitives. It is therefore time to
enlist the aid of lockdep.
This set of patches is inspired by earlier work by Peter
Zijlstra and Thomas Gleixner, and takes the following approach:
o Set up separate lockdep classes for RCU, RCU-bh, and RCU-sched.
o Set up separate lockdep classes for each instance of SRCU.
o Create primitives that check for being in an RCU read-side
critical section. These return exact answers if lockdep is
fully enabled, but if unsure, report being in an RCU read-side
critical section. (We want to avoid false positives!)
The primitives are:
For RCU: rcu_read_lock_held(void)
For RCU-bh: rcu_read_lock_bh_held(void)
For RCU-sched: rcu_read_lock_sched_held(void)
For SRCU: srcu_read_lock_held(struct srcu_struct *sp)
o Add rcu_dereference_check(), which takes a second argument
in which one places a boolean expression based on the above
primitives and/or lockdep_is_held().
o A new kernel configuration parameter, CONFIG_PROVE_RCU, enables
rcu_dereference_check(). This depends on CONFIG_PROVE_LOCKING,
and should be quite helpful during the transition period while
CONFIG_PROVE_RCU-unaware patches are in flight.
The existing rcu_dereference() primitive does no checking, but
upcoming patches will change that.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: laijs@cn.fujitsu.com
Cc: dipankar@in.ibm.com
Cc: mathieu.desnoyers@polymtl.ca
Cc: josh@joshtriplett.org
Cc: dvhltc@us.ibm.com
Cc: niv@us.ibm.com
Cc: peterz@infradead.org
Cc: rostedt@goodmis.org
Cc: Valdis.Kletnieks@vt.edu
Cc: dhowells@redhat.com
LKML-Reference: <1266887105-1528-1-git-send-email-paulmck@linux.vnet.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-02-23 09:04:45 +08:00
|
|
|
EXPORT_SYMBOL_GPL(rcu_bh_lock_map);
|
|
|
|
|
|
|
|
static struct lock_class_key rcu_sched_lock_key;
|
lockdep: Introduce wait-type checks
Extend lockdep to validate lock wait-type context.
The current wait-types are:
LD_WAIT_FREE, /* wait free, rcu etc.. */
LD_WAIT_SPIN, /* spin loops, raw_spinlock_t etc.. */
LD_WAIT_CONFIG, /* CONFIG_PREEMPT_LOCK, spinlock_t etc.. */
LD_WAIT_SLEEP, /* sleeping locks, mutex_t etc.. */
Where lockdep validates that the current lock (the one being acquired)
fits in the current wait-context (as generated by the held stack).
This ensures that there is no attempt to acquire mutexes while holding
spinlocks, to acquire spinlocks while holding raw_spinlocks and so on. In
other words, its a more fancy might_sleep().
Obviously RCU made the entire ordeal more complex than a simple single
value test because RCU can be acquired in (pretty much) any context and
while it presents a context to nested locks it is not the same as it
got acquired in.
Therefore its necessary to split the wait_type into two values, one
representing the acquire (outer) and one representing the nested context
(inner). For most 'normal' locks these two are the same.
[ To make static initialization easier we have the rule that:
.outer == INV means .outer == .inner; because INV == 0. ]
It further means that its required to find the minimal .inner of the held
stack to compare against the outer of the new lock; because while 'normal'
RCU presents a CONFIG type to nested locks, if it is taken while already
holding a SPIN type it obviously doesn't relax the rules.
Below is an example output generated by the trivial test code:
raw_spin_lock(&foo);
spin_lock(&bar);
spin_unlock(&bar);
raw_spin_unlock(&foo);
[ BUG: Invalid wait context ]
-----------------------------
swapper/0/1 is trying to lock:
ffffc90000013f20 (&bar){....}-{3:3}, at: kernel_init+0xdb/0x187
other info that might help us debug this:
1 lock held by swapper/0/1:
#0: ffffc90000013ee0 (&foo){+.+.}-{2:2}, at: kernel_init+0xd1/0x187
The way to read it is to look at the new -{n,m} part in the lock
description; -{3:3} for the attempted lock, and try and match that up to
the held locks, which in this case is the one: -{2,2}.
This tells that the acquiring lock requires a more relaxed environment than
presented by the lock stack.
Currently only the normal locks and RCU are converted, the rest of the
lockdep users defaults to .inner = INV which is ignored. More conversions
can be done when desired.
The check for spinlock_t nesting is not enabled by default. It's a separate
config option for now as there are known problems which are currently
addressed. The config option allows to identify these problems and to
verify that the solutions found are indeed solving them.
The config switch will be removed and the checks will permanently enabled
once the vast majority of issues has been addressed.
[ bigeasy: Move LD_WAIT_FREE,… out of CONFIG_LOCKDEP to avoid compile
failure with CONFIG_DEBUG_SPINLOCK + !CONFIG_LOCKDEP]
[ tglx: Add the config option ]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200321113242.427089655@linutronix.de
2020-03-21 19:26:01 +08:00
|
|
|
struct lockdep_map rcu_sched_lock_map = {
|
|
|
|
.name = "rcu_read_lock_sched",
|
|
|
|
.key = &rcu_sched_lock_key,
|
|
|
|
.wait_type_outer = LD_WAIT_FREE,
|
|
|
|
.wait_type_inner = LD_WAIT_SPIN,
|
|
|
|
};
|
rcu: Introduce lockdep-based checking to RCU read-side primitives
Inspection is proving insufficient to catch all RCU misuses,
which is understandable given that rcu_dereference() might be
protected by any of four different flavors of RCU (RCU, RCU-bh,
RCU-sched, and SRCU), and might also/instead be protected by any
of a number of locking primitives. It is therefore time to
enlist the aid of lockdep.
This set of patches is inspired by earlier work by Peter
Zijlstra and Thomas Gleixner, and takes the following approach:
o Set up separate lockdep classes for RCU, RCU-bh, and RCU-sched.
o Set up separate lockdep classes for each instance of SRCU.
o Create primitives that check for being in an RCU read-side
critical section. These return exact answers if lockdep is
fully enabled, but if unsure, report being in an RCU read-side
critical section. (We want to avoid false positives!)
The primitives are:
For RCU: rcu_read_lock_held(void)
For RCU-bh: rcu_read_lock_bh_held(void)
For RCU-sched: rcu_read_lock_sched_held(void)
For SRCU: srcu_read_lock_held(struct srcu_struct *sp)
o Add rcu_dereference_check(), which takes a second argument
in which one places a boolean expression based on the above
primitives and/or lockdep_is_held().
o A new kernel configuration parameter, CONFIG_PROVE_RCU, enables
rcu_dereference_check(). This depends on CONFIG_PROVE_LOCKING,
and should be quite helpful during the transition period while
CONFIG_PROVE_RCU-unaware patches are in flight.
The existing rcu_dereference() primitive does no checking, but
upcoming patches will change that.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: laijs@cn.fujitsu.com
Cc: dipankar@in.ibm.com
Cc: mathieu.desnoyers@polymtl.ca
Cc: josh@joshtriplett.org
Cc: dvhltc@us.ibm.com
Cc: niv@us.ibm.com
Cc: peterz@infradead.org
Cc: rostedt@goodmis.org
Cc: Valdis.Kletnieks@vt.edu
Cc: dhowells@redhat.com
LKML-Reference: <1266887105-1528-1-git-send-email-paulmck@linux.vnet.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-02-23 09:04:45 +08:00
|
|
|
EXPORT_SYMBOL_GPL(rcu_sched_lock_map);
|
2010-03-16 08:03:43 +08:00
|
|
|
|
2020-05-04 10:16:09 +08:00
|
|
|
// Tell lockdep when RCU callbacks are being invoked.
|
2013-10-29 00:22:24 +08:00
|
|
|
static struct lock_class_key rcu_callback_key;
|
|
|
|
struct lockdep_map rcu_callback_map =
|
|
|
|
STATIC_LOCKDEP_MAP_INIT("rcu_callback", &rcu_callback_key);
|
|
|
|
EXPORT_SYMBOL_GPL(rcu_callback_map);
|
|
|
|
|
2020-03-14 00:32:17 +08:00
|
|
|
noinstr int notrace debug_lockdep_rcu_enabled(void)
|
2010-04-16 03:50:39 +08:00
|
|
|
{
|
rcu: Narrow early boot window of illegal synchronous grace periods
The current preemptible RCU implementation goes through three phases
during bootup. In the first phase, there is only one CPU that is running
with preemption disabled, so that a no-op is a synchronous grace period.
In the second mid-boot phase, the scheduler is running, but RCU has
not yet gotten its kthreads spawned (and, for expedited grace periods,
workqueues are not yet running. During this time, any attempt to do
a synchronous grace period will hang the system (or complain bitterly,
depending). In the third and final phase, RCU is fully operational and
everything works normally.
This has been OK for some time, but there has recently been some
synchronous grace periods showing up during the second mid-boot phase.
This code worked "by accident" for awhile, but started failing as soon
as expedited RCU grace periods switched over to workqueues in commit
8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue").
Note that the code was buggy even before this commit, as it was subject
to failure on real-time systems that forced all expedited grace periods
to run as normal grace periods (for example, using the rcu_normal ksysfs
parameter). The callchain from the failure case is as follows:
early_amd_iommu_init()
|-> acpi_put_table(ivrs_base);
|-> acpi_tb_put_table(table_desc);
|-> acpi_tb_invalidate_table(table_desc);
|-> acpi_tb_release_table(...)
|-> acpi_os_unmap_memory
|-> acpi_os_unmap_iomem
|-> acpi_os_map_cleanup
|-> synchronize_rcu_expedited
The kernel showing this callchain was built with CONFIG_PREEMPT_RCU=y,
which caused the code to try using workqueues before they were
initialized, which did not go well.
This commit therefore reworks RCU to permit synchronous grace periods
to proceed during this mid-boot phase. This commit is therefore a
fix to a regression introduced in v4.9, and is therefore being put
forward post-merge-window in v4.10.
This commit sets a flag from the existing rcu_scheduler_starting()
function which causes all synchronous grace periods to take the expedited
path. The expedited path now checks this flag, using the requesting task
to drive the expedited grace period forward during the mid-boot phase.
Finally, this flag is updated by a core_initcall() function named
rcu_exp_runtime_mode(), which causes the runtime codepaths to be used.
Note that this arrangement assumes that tasks are not sent POSIX signals
(or anything similar) from the time that the first task is spawned
through core_initcall() time.
Fixes: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
Reported-by: "Zheng, Lv" <lv.zheng@intel.com>
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Stan Kain <stan.kain@gmail.com>
Tested-by: Ivan <waffolz@hotmail.com>
Tested-by: Emanuel Castelo <emanuel.castelo@gmail.com>
Tested-by: Bruno Pesavento <bpesavento@infinito.it>
Tested-by: Borislav Petkov <bp@suse.de>
Tested-by: Frederic Bezies <fredbezies@gmail.com>
Cc: <stable@vger.kernel.org> # 4.9.0-
2017-01-10 18:28:26 +08:00
|
|
|
return rcu_scheduler_active != RCU_SCHEDULER_INACTIVE && debug_locks &&
|
2010-04-16 03:50:39 +08:00
|
|
|
current->lockdep_recursion == 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(debug_lockdep_rcu_enabled);
|
|
|
|
|
2014-07-09 06:17:59 +08:00
|
|
|
/**
|
|
|
|
* rcu_read_lock_held() - might we be in RCU read-side critical section?
|
|
|
|
*
|
|
|
|
* If CONFIG_DEBUG_LOCK_ALLOC is selected, returns nonzero iff in an RCU
|
|
|
|
* read-side critical section. In absence of CONFIG_DEBUG_LOCK_ALLOC,
|
|
|
|
* this assumes we are in an RCU read-side critical section unless it can
|
|
|
|
* prove otherwise. This is useful for debug checks in functions that
|
|
|
|
* require that they be called within an RCU read-side critical section.
|
|
|
|
*
|
|
|
|
* Checks debug_lockdep_rcu_enabled() to prevent false positives during boot
|
|
|
|
* and while lockdep is disabled.
|
|
|
|
*
|
|
|
|
* Note that rcu_read_lock() and the matching rcu_read_unlock() must
|
|
|
|
* occur in the same context, for example, it is illegal to invoke
|
|
|
|
* rcu_read_unlock() in process context if the matching rcu_read_lock()
|
|
|
|
* was invoked from within an irq handler.
|
|
|
|
*
|
|
|
|
* Note that rcu_read_lock() is disallowed if the CPU is either idle or
|
|
|
|
* offline from an RCU perspective, so check for those as well.
|
|
|
|
*/
|
|
|
|
int rcu_read_lock_held(void)
|
|
|
|
{
|
2019-07-17 06:12:22 +08:00
|
|
|
bool ret;
|
|
|
|
|
|
|
|
if (rcu_read_lock_held_common(&ret))
|
|
|
|
return ret;
|
2014-07-09 06:17:59 +08:00
|
|
|
return lock_is_held(&rcu_lock_map);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(rcu_read_lock_held);
|
|
|
|
|
2010-03-16 08:03:43 +08:00
|
|
|
/**
|
2010-04-29 05:39:09 +08:00
|
|
|
* rcu_read_lock_bh_held() - might we be in RCU-bh read-side critical section?
|
2010-03-16 08:03:43 +08:00
|
|
|
*
|
|
|
|
* Check for bottom half being disabled, which covers both the
|
|
|
|
* CONFIG_PROVE_RCU and not cases. Note that if someone uses
|
|
|
|
* rcu_read_lock_bh(), but then later enables BH, lockdep (if enabled)
|
2010-04-29 05:39:09 +08:00
|
|
|
* will show the situation. This is useful for debug checks in functions
|
|
|
|
* that require that they be called within an RCU read-side critical
|
|
|
|
* section.
|
2010-03-16 08:03:43 +08:00
|
|
|
*
|
|
|
|
* Check debug_lockdep_rcu_enabled() to prevent false positives during boot.
|
2012-01-24 04:41:26 +08:00
|
|
|
*
|
2018-07-03 00:04:27 +08:00
|
|
|
* Note that rcu_read_lock_bh() is disallowed if the CPU is either idle or
|
2012-01-24 04:41:26 +08:00
|
|
|
* offline from an RCU perspective, so check for those as well.
|
2010-03-16 08:03:43 +08:00
|
|
|
*/
|
|
|
|
int rcu_read_lock_bh_held(void)
|
|
|
|
{
|
2019-07-17 06:12:22 +08:00
|
|
|
bool ret;
|
|
|
|
|
|
|
|
if (rcu_read_lock_held_common(&ret))
|
|
|
|
return ret;
|
2010-10-06 05:03:02 +08:00
|
|
|
return in_softirq() || irqs_disabled();
|
2010-03-16 08:03:43 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(rcu_read_lock_bh_held);
|
|
|
|
|
2019-07-17 06:12:22 +08:00
|
|
|
int rcu_read_lock_any_held(void)
|
|
|
|
{
|
|
|
|
bool ret;
|
|
|
|
|
|
|
|
if (rcu_read_lock_held_common(&ret))
|
|
|
|
return ret;
|
|
|
|
if (lock_is_held(&rcu_lock_map) ||
|
|
|
|
lock_is_held(&rcu_bh_lock_map) ||
|
|
|
|
lock_is_held(&rcu_sched_lock_map))
|
|
|
|
return 1;
|
|
|
|
return !preemptible();
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(rcu_read_lock_any_held);
|
|
|
|
|
2010-03-16 08:03:43 +08:00
|
|
|
#endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
|
|
|
|
|
2015-01-11 11:47:10 +08:00
|
|
|
/**
|
|
|
|
* wakeme_after_rcu() - Callback function to awaken a task after grace period
|
|
|
|
* @head: Pointer to rcu_head member within rcu_synchronize structure
|
|
|
|
*
|
|
|
|
* Awaken the corresponding task now that a grace period has elapsed.
|
2008-02-14 07:03:15 +08:00
|
|
|
*/
|
2015-01-11 11:47:10 +08:00
|
|
|
void wakeme_after_rcu(struct rcu_head *head)
|
2006-03-08 13:55:33 +08:00
|
|
|
{
|
2008-01-26 04:08:24 +08:00
|
|
|
struct rcu_synchronize *rcu;
|
|
|
|
|
|
|
|
rcu = container_of(head, struct rcu_synchronize, head);
|
|
|
|
complete(&rcu->completion);
|
2006-03-08 13:55:33 +08:00
|
|
|
}
|
2015-06-11 03:53:06 +08:00
|
|
|
EXPORT_SYMBOL_GPL(wakeme_after_rcu);
|
2010-05-07 00:28:41 +08:00
|
|
|
|
2015-06-11 03:53:06 +08:00
|
|
|
void __wait_rcu_gp(bool checktiny, int n, call_rcu_func_t *crcu_array,
|
|
|
|
struct rcu_synchronize *rs_array)
|
2011-05-27 13:14:36 +08:00
|
|
|
{
|
2015-06-11 03:53:06 +08:00
|
|
|
int i;
|
2017-04-29 07:19:07 +08:00
|
|
|
int j;
|
2015-06-11 03:53:06 +08:00
|
|
|
|
2018-07-09 01:58:37 +08:00
|
|
|
/* Initialize and register callbacks for each crcu_array element. */
|
2015-06-11 03:53:06 +08:00
|
|
|
for (i = 0; i < n; i++) {
|
|
|
|
if (checktiny &&
|
2018-07-12 05:36:49 +08:00
|
|
|
(crcu_array[i] == call_rcu)) {
|
2015-06-11 03:53:06 +08:00
|
|
|
might_sleep();
|
|
|
|
continue;
|
|
|
|
}
|
2017-04-29 07:19:07 +08:00
|
|
|
for (j = 0; j < i; j++)
|
|
|
|
if (crcu_array[j] == crcu_array[i])
|
|
|
|
break;
|
2020-04-16 06:26:55 +08:00
|
|
|
if (j == i) {
|
|
|
|
init_rcu_head_on_stack(&rs_array[i].head);
|
|
|
|
init_completion(&rs_array[i].completion);
|
2017-04-29 07:19:07 +08:00
|
|
|
(crcu_array[i])(&rs_array[i].head, wakeme_after_rcu);
|
2020-04-16 06:26:55 +08:00
|
|
|
}
|
2015-06-11 03:53:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Wait for all callbacks to be invoked. */
|
|
|
|
for (i = 0; i < n; i++) {
|
|
|
|
if (checktiny &&
|
2018-07-12 05:36:49 +08:00
|
|
|
(crcu_array[i] == call_rcu))
|
2015-06-11 03:53:06 +08:00
|
|
|
continue;
|
2017-04-29 07:19:07 +08:00
|
|
|
for (j = 0; j < i; j++)
|
|
|
|
if (crcu_array[j] == crcu_array[i])
|
|
|
|
break;
|
2020-04-16 06:26:55 +08:00
|
|
|
if (j == i) {
|
2017-04-29 07:19:07 +08:00
|
|
|
wait_for_completion(&rs_array[i].completion);
|
2020-04-16 06:26:55 +08:00
|
|
|
destroy_rcu_head_on_stack(&rs_array[i].head);
|
|
|
|
}
|
2015-06-11 03:53:06 +08:00
|
|
|
}
|
2011-05-27 13:14:36 +08:00
|
|
|
}
|
2015-06-11 03:53:06 +08:00
|
|
|
EXPORT_SYMBOL_GPL(__wait_rcu_gp);
|
2011-05-27 13:14:36 +08:00
|
|
|
|
2010-04-17 20:48:42 +08:00
|
|
|
#ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
|
2014-06-20 05:57:10 +08:00
|
|
|
void init_rcu_head(struct rcu_head *head)
|
2010-04-17 20:48:42 +08:00
|
|
|
{
|
|
|
|
debug_object_init(head, &rcuhead_debug_descr);
|
|
|
|
}
|
2017-12-08 01:40:38 +08:00
|
|
|
EXPORT_SYMBOL_GPL(init_rcu_head);
|
2010-04-17 20:48:42 +08:00
|
|
|
|
2014-06-20 05:57:10 +08:00
|
|
|
void destroy_rcu_head(struct rcu_head *head)
|
2010-04-17 20:48:42 +08:00
|
|
|
{
|
|
|
|
debug_object_free(head, &rcuhead_debug_descr);
|
|
|
|
}
|
2017-12-08 01:40:38 +08:00
|
|
|
EXPORT_SYMBOL_GPL(destroy_rcu_head);
|
2010-04-17 20:48:42 +08:00
|
|
|
|
2016-05-20 08:09:41 +08:00
|
|
|
static bool rcuhead_is_static_object(void *addr)
|
2010-04-17 20:48:42 +08:00
|
|
|
{
|
2016-05-20 08:09:41 +08:00
|
|
|
return true;
|
2010-04-17 20:48:42 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* init_rcu_head_on_stack() - initialize on-stack rcu_head for debugobjects
|
|
|
|
* @head: pointer to rcu_head structure to be initialized
|
|
|
|
*
|
|
|
|
* This function informs debugobjects of a new rcu_head structure that
|
|
|
|
* has been allocated as an auto variable on the stack. This function
|
|
|
|
* is not required for rcu_head structures that are statically defined or
|
|
|
|
* that are dynamically allocated on the heap. This function has no
|
|
|
|
* effect for !CONFIG_DEBUG_OBJECTS_RCU_HEAD kernel builds.
|
|
|
|
*/
|
|
|
|
void init_rcu_head_on_stack(struct rcu_head *head)
|
|
|
|
{
|
|
|
|
debug_object_init_on_stack(head, &rcuhead_debug_descr);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(init_rcu_head_on_stack);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* destroy_rcu_head_on_stack() - destroy on-stack rcu_head for debugobjects
|
|
|
|
* @head: pointer to rcu_head structure to be initialized
|
|
|
|
*
|
|
|
|
* This function informs debugobjects that an on-stack rcu_head structure
|
|
|
|
* is about to go out of scope. As with init_rcu_head_on_stack(), this
|
|
|
|
* function is not required for rcu_head structures that are statically
|
|
|
|
* defined or that are dynamically allocated on the heap. Also as with
|
|
|
|
* init_rcu_head_on_stack(), this function has no effect for
|
|
|
|
* !CONFIG_DEBUG_OBJECTS_RCU_HEAD kernel builds.
|
|
|
|
*/
|
|
|
|
void destroy_rcu_head_on_stack(struct rcu_head *head)
|
|
|
|
{
|
|
|
|
debug_object_free(head, &rcuhead_debug_descr);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(destroy_rcu_head_on_stack);
|
|
|
|
|
|
|
|
struct debug_obj_descr rcuhead_debug_descr = {
|
|
|
|
.name = "rcu_head",
|
2016-05-20 08:09:41 +08:00
|
|
|
.is_static_object = rcuhead_is_static_object,
|
2010-04-17 20:48:42 +08:00
|
|
|
};
|
|
|
|
EXPORT_SYMBOL_GPL(rcuhead_debug_descr);
|
|
|
|
#endif /* #ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD */
|
2011-10-02 22:44:32 +08:00
|
|
|
|
2019-10-15 10:55:57 +08:00
|
|
|
#if defined(CONFIG_TREE_RCU) || defined(CONFIG_RCU_TRACE)
|
2013-07-13 04:50:28 +08:00
|
|
|
void do_trace_rcu_torture_read(const char *rcutorturename, struct rcu_head *rhp,
|
2012-11-15 08:26:40 +08:00
|
|
|
unsigned long secs,
|
|
|
|
unsigned long c_old, unsigned long c)
|
2011-10-02 22:44:32 +08:00
|
|
|
{
|
2012-11-15 08:26:40 +08:00
|
|
|
trace_rcu_torture_read(rcutorturename, rhp, secs, c_old, c);
|
2011-10-02 22:44:32 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(do_trace_rcu_torture_read);
|
|
|
|
#else
|
2012-11-15 08:26:40 +08:00
|
|
|
#define do_trace_rcu_torture_read(rcutorturename, rhp, secs, c_old, c) \
|
|
|
|
do { } while (0)
|
2011-10-02 22:44:32 +08:00
|
|
|
#endif
|
2012-10-20 03:49:17 +08:00
|
|
|
|
rcutorture: Add trivial RCU implementation
I have been showing off a trivial RCU implementation for non-preemptive
environments for some time now:
#define rcu_read_lock()
#define rcu_read_unlock()
#define rcu_dereference(p) READ_ONCE(p)
#define rcu_assign_pointer(p, v) smp_store_release(&(p), (v))
void synchronize_rcu(void)
{
int cpu;
for_each_online_cpu(cpu)
sched_setaffinity(current->pid, cpumask_of(cpu));
}
Trivial or not, as the old saying goes, "if it ain't tested, it don't
work!". This commit therefore adds a "trivial" flavor to rcutorture
and a corresponding TRIVIAL test scenario. This variant does not handle
CPU hotplug, which is unconditionally enabled on x86 for post-v5.1-rc3
kernels, which is why the TRIVIAL.boot says "rcutorture.onoff_interval=0".
This commit actually does handle CONFIG_PREEMPT=y kernels, but only
because it turns back the Linux-kernel clock in order to provide these
alternative definitions (or the moral equivalent thereof):
#define rcu_read_lock() preempt_disable()
#define rcu_read_unlock() preempt_enable()
In CONFIG_PREEMPT=n kernels without debugging, these are equivalent to
empty macros give or take a compiler barrier. However, the have been
successfully tested with actual empty macros as well.
Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
[ paulmck: Fix symbol issue reported by kbuild test robot <lkp@intel.com>. ]
[ paulmck: Work around sched_setaffinity() issue noted by Andrea Parri. ]
[ paulmck: Add rcutorture.shuffle_interval=0 to TRIVIAL.boot to fix
interaction with shuffler task noted by Peter Zijlstra. ]
Tested-by: Andrea Parri <andrea.parri@amarulasolutions.com>
2019-04-19 22:38:27 +08:00
|
|
|
#if IS_ENABLED(CONFIG_RCU_TORTURE_TEST) || IS_MODULE(CONFIG_RCU_TORTURE_TEST)
|
|
|
|
/* Get rcutorture access to sched_setaffinity(). */
|
|
|
|
long rcutorture_sched_setaffinity(pid_t pid, const struct cpumask *in_mask)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = sched_setaffinity(pid, in_mask);
|
|
|
|
WARN_ONCE(ret, "%s: sched_setaffinity() returned %d\n", __func__, ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(rcutorture_sched_setaffinity);
|
|
|
|
#endif
|
|
|
|
|
2012-10-20 03:49:17 +08:00
|
|
|
#ifdef CONFIG_RCU_STALL_COMMON
|
2019-06-14 06:30:49 +08:00
|
|
|
int rcu_cpu_stall_ftrace_dump __read_mostly;
|
|
|
|
module_param(rcu_cpu_stall_ftrace_dump, int, 0644);
|
2019-12-06 03:29:01 +08:00
|
|
|
int rcu_cpu_stall_suppress __read_mostly; // !0 = suppress stall warnings.
|
2017-09-02 05:40:54 +08:00
|
|
|
EXPORT_SYMBOL_GPL(rcu_cpu_stall_suppress);
|
2012-10-20 03:49:17 +08:00
|
|
|
module_param(rcu_cpu_stall_suppress, int, 0644);
|
2019-01-12 08:10:57 +08:00
|
|
|
int rcu_cpu_stall_timeout __read_mostly = CONFIG_RCU_CPU_STALL_TIMEOUT;
|
2012-10-20 03:49:17 +08:00
|
|
|
module_param(rcu_cpu_stall_timeout, int, 0644);
|
|
|
|
#endif /* #ifdef CONFIG_RCU_STALL_COMMON */
|
2014-06-28 04:42:20 +08:00
|
|
|
|
2019-12-06 03:29:01 +08:00
|
|
|
// Suppress boot-time RCU CPU stall warnings and rcutorture writer stall
|
|
|
|
// warnings. Also used by rcutorture even if stall warnings are excluded.
|
|
|
|
int rcu_cpu_stall_suppress_at_boot __read_mostly; // !0 = suppress boot stalls.
|
|
|
|
EXPORT_SYMBOL_GPL(rcu_cpu_stall_suppress_at_boot);
|
|
|
|
module_param(rcu_cpu_stall_suppress_at_boot, int, 0444);
|
|
|
|
|
2014-09-19 23:32:29 +08:00
|
|
|
#ifdef CONFIG_PROVE_RCU
|
|
|
|
|
|
|
|
/*
|
2018-07-08 01:24:23 +08:00
|
|
|
* Early boot self test parameters.
|
2014-09-19 23:32:29 +08:00
|
|
|
*/
|
|
|
|
static bool rcu_self_test;
|
|
|
|
module_param(rcu_self_test, bool, 0444);
|
|
|
|
|
|
|
|
static int rcu_self_test_counter;
|
|
|
|
|
|
|
|
static void test_callback(struct rcu_head *r)
|
|
|
|
{
|
|
|
|
rcu_self_test_counter++;
|
|
|
|
pr_info("RCU test callback executed %d\n", rcu_self_test_counter);
|
|
|
|
}
|
|
|
|
|
srcu: Make call_srcu() available during very early boot
Event tracing is moving to SRCU in order to take advantage of the fact
that SRCU may be safely used from idle and even offline CPUs. However,
event tracing can invoke call_srcu() very early in the boot process,
even before workqueue_init_early() is invoked (let alone rcu_init()).
Therefore, call_srcu()'s attempts to queue work fail miserably.
This commit therefore detects this situation, and refrains from attempting
to queue work before rcu_init() time, but does everything else that it
would have done, and in addition, adds the srcu_struct to a global list.
The rcu_init() function now invokes a new srcu_init() function, which
is empty if CONFIG_SRCU=n. Otherwise, srcu_init() queues work for
each srcu_struct on the list. This all happens early enough in boot
that there is but a single CPU with interrupts disabled, which allows
synchronization to be dispensed with.
Of course, the queued work won't actually be invoked until after
workqueue_init() is invoked, which happens shortly after the scheduler
is up and running. This means that although call_srcu() may be invoked
any time after per-CPU variables have been set up, there is still a very
narrow window when synchronize_srcu() won't work, and this window
extends from the time that the scheduler starts until the time that
workqueue_init() returns. This can be fixed in a manner similar to
the fix for synchronize_rcu_expedited() and friends, but until someone
actually needs to use synchronize_srcu() during this window, this fix
is added churn for no benefit.
Finally, note that Tree SRCU's new srcu_init() function invokes
queue_work() rather than the queue_delayed_work() function that is
invoked post-boot. The reason is that queue_delayed_work() will (as you
would expect) post a timer, and timers have not yet been initialized.
So use of queue_work() avoids the complaints about use of uninitialized
spinlocks that would otherwise result. Besides, some delay is already
provide by the aforementioned fact that the queued work won't actually
be invoked until after the scheduler is up and running.
Requested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2018-08-14 23:45:54 +08:00
|
|
|
DEFINE_STATIC_SRCU(early_srcu);
|
|
|
|
|
rcu: Add basic support for kfree_rcu() batching
Recently a discussion about stability and performance of a system
involving a high rate of kfree_rcu() calls surfaced on the list [1]
which led to another discussion how to prepare for this situation.
This patch adds basic batching support for kfree_rcu(). It is "basic"
because we do none of the slab management, dynamic allocation, code
moving or any of the other things, some of which previous attempts did
[2]. These fancier improvements can be follow-up patches and there are
different ideas being discussed in those regards. This is an effort to
start simple, and build up from there. In the future, an extension to
use kfree_bulk and possibly per-slab batching could be done to further
improve performance due to cache-locality and slab-specific bulk free
optimizations. By using an array of pointers, the worker thread
processing the work would need to read lesser data since it does not
need to deal with large rcu_head(s) any longer.
Torture tests follow in the next patch and show improvements of around
5x reduction in number of grace periods on a 16 CPU system. More
details and test data are in that patch.
There is an implication with rcu_barrier() with this patch. Since the
kfree_rcu() calls can be batched, and may not be handed yet to the RCU
machinery in fact, the monitor may not have even run yet to do the
queue_rcu_work(), there seems no easy way of implementing rcu_barrier()
to wait for those kfree_rcu()s that are already made. So this means a
kfree_rcu() followed by an rcu_barrier() does not imply that memory will
be freed once rcu_barrier() returns.
Another implication is higher active memory usage (although not
run-away..) until the kfree_rcu() flooding ends, in comparison to
without batching. More details about this are in the second patch which
adds an rcuperf test.
Finally, in the near future we will get rid of kfree_rcu() special casing
within RCU such as in rcu_do_batch and switch everything to just
batching. Currently we don't do that since timer subsystem is not yet up
and we cannot schedule the kfree_rcu() monitor as the timer subsystem's
lock are not initialized. That would also mean getting rid of
kfree_call_rcu_nobatch() entirely.
[1] http://lore.kernel.org/lkml/20190723035725-mutt-send-email-mst@kernel.org
[2] https://lkml.org/lkml/2017/12/19/824
Cc: kernel-team@android.com
Cc: kernel-team@lge.com
Co-developed-by: Byungchul Park <byungchul.park@lge.com>
Signed-off-by: Byungchul Park <byungchul.park@lge.com>
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
[ paulmck: Applied 0day and Paul Walmsley feedback on ->monitor_todo. ]
[ paulmck: Make it work during early boot. ]
[ paulmck: Add a crude early boot self-test. ]
[ paulmck: Style adjustments and experimental docbook structure header. ]
Link: https://lore.kernel.org/lkml/alpine.DEB.2.21.9999.1908161931110.32497@viisi.sifive.com/T/#me9956f66cb611b95d26ae92700e1d901f46e8c59
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2019-08-06 06:22:27 +08:00
|
|
|
struct early_boot_kfree_rcu {
|
|
|
|
struct rcu_head rh;
|
|
|
|
};
|
|
|
|
|
2014-09-19 23:32:29 +08:00
|
|
|
static void early_boot_test_call_rcu(void)
|
|
|
|
{
|
|
|
|
static struct rcu_head head;
|
srcu: Make call_srcu() available during very early boot
Event tracing is moving to SRCU in order to take advantage of the fact
that SRCU may be safely used from idle and even offline CPUs. However,
event tracing can invoke call_srcu() very early in the boot process,
even before workqueue_init_early() is invoked (let alone rcu_init()).
Therefore, call_srcu()'s attempts to queue work fail miserably.
This commit therefore detects this situation, and refrains from attempting
to queue work before rcu_init() time, but does everything else that it
would have done, and in addition, adds the srcu_struct to a global list.
The rcu_init() function now invokes a new srcu_init() function, which
is empty if CONFIG_SRCU=n. Otherwise, srcu_init() queues work for
each srcu_struct on the list. This all happens early enough in boot
that there is but a single CPU with interrupts disabled, which allows
synchronization to be dispensed with.
Of course, the queued work won't actually be invoked until after
workqueue_init() is invoked, which happens shortly after the scheduler
is up and running. This means that although call_srcu() may be invoked
any time after per-CPU variables have been set up, there is still a very
narrow window when synchronize_srcu() won't work, and this window
extends from the time that the scheduler starts until the time that
workqueue_init() returns. This can be fixed in a manner similar to
the fix for synchronize_rcu_expedited() and friends, but until someone
actually needs to use synchronize_srcu() during this window, this fix
is added churn for no benefit.
Finally, note that Tree SRCU's new srcu_init() function invokes
queue_work() rather than the queue_delayed_work() function that is
invoked post-boot. The reason is that queue_delayed_work() will (as you
would expect) post a timer, and timers have not yet been initialized.
So use of queue_work() avoids the complaints about use of uninitialized
spinlocks that would otherwise result. Besides, some delay is already
provide by the aforementioned fact that the queued work won't actually
be invoked until after the scheduler is up and running.
Requested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2018-08-14 23:45:54 +08:00
|
|
|
static struct rcu_head shead;
|
rcu: Add basic support for kfree_rcu() batching
Recently a discussion about stability and performance of a system
involving a high rate of kfree_rcu() calls surfaced on the list [1]
which led to another discussion how to prepare for this situation.
This patch adds basic batching support for kfree_rcu(). It is "basic"
because we do none of the slab management, dynamic allocation, code
moving or any of the other things, some of which previous attempts did
[2]. These fancier improvements can be follow-up patches and there are
different ideas being discussed in those regards. This is an effort to
start simple, and build up from there. In the future, an extension to
use kfree_bulk and possibly per-slab batching could be done to further
improve performance due to cache-locality and slab-specific bulk free
optimizations. By using an array of pointers, the worker thread
processing the work would need to read lesser data since it does not
need to deal with large rcu_head(s) any longer.
Torture tests follow in the next patch and show improvements of around
5x reduction in number of grace periods on a 16 CPU system. More
details and test data are in that patch.
There is an implication with rcu_barrier() with this patch. Since the
kfree_rcu() calls can be batched, and may not be handed yet to the RCU
machinery in fact, the monitor may not have even run yet to do the
queue_rcu_work(), there seems no easy way of implementing rcu_barrier()
to wait for those kfree_rcu()s that are already made. So this means a
kfree_rcu() followed by an rcu_barrier() does not imply that memory will
be freed once rcu_barrier() returns.
Another implication is higher active memory usage (although not
run-away..) until the kfree_rcu() flooding ends, in comparison to
without batching. More details about this are in the second patch which
adds an rcuperf test.
Finally, in the near future we will get rid of kfree_rcu() special casing
within RCU such as in rcu_do_batch and switch everything to just
batching. Currently we don't do that since timer subsystem is not yet up
and we cannot schedule the kfree_rcu() monitor as the timer subsystem's
lock are not initialized. That would also mean getting rid of
kfree_call_rcu_nobatch() entirely.
[1] http://lore.kernel.org/lkml/20190723035725-mutt-send-email-mst@kernel.org
[2] https://lkml.org/lkml/2017/12/19/824
Cc: kernel-team@android.com
Cc: kernel-team@lge.com
Co-developed-by: Byungchul Park <byungchul.park@lge.com>
Signed-off-by: Byungchul Park <byungchul.park@lge.com>
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
[ paulmck: Applied 0day and Paul Walmsley feedback on ->monitor_todo. ]
[ paulmck: Make it work during early boot. ]
[ paulmck: Add a crude early boot self-test. ]
[ paulmck: Style adjustments and experimental docbook structure header. ]
Link: https://lore.kernel.org/lkml/alpine.DEB.2.21.9999.1908161931110.32497@viisi.sifive.com/T/#me9956f66cb611b95d26ae92700e1d901f46e8c59
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2019-08-06 06:22:27 +08:00
|
|
|
struct early_boot_kfree_rcu *rhp;
|
2014-09-19 23:32:29 +08:00
|
|
|
|
|
|
|
call_rcu(&head, test_callback);
|
srcu: Make call_srcu() available during very early boot
Event tracing is moving to SRCU in order to take advantage of the fact
that SRCU may be safely used from idle and even offline CPUs. However,
event tracing can invoke call_srcu() very early in the boot process,
even before workqueue_init_early() is invoked (let alone rcu_init()).
Therefore, call_srcu()'s attempts to queue work fail miserably.
This commit therefore detects this situation, and refrains from attempting
to queue work before rcu_init() time, but does everything else that it
would have done, and in addition, adds the srcu_struct to a global list.
The rcu_init() function now invokes a new srcu_init() function, which
is empty if CONFIG_SRCU=n. Otherwise, srcu_init() queues work for
each srcu_struct on the list. This all happens early enough in boot
that there is but a single CPU with interrupts disabled, which allows
synchronization to be dispensed with.
Of course, the queued work won't actually be invoked until after
workqueue_init() is invoked, which happens shortly after the scheduler
is up and running. This means that although call_srcu() may be invoked
any time after per-CPU variables have been set up, there is still a very
narrow window when synchronize_srcu() won't work, and this window
extends from the time that the scheduler starts until the time that
workqueue_init() returns. This can be fixed in a manner similar to
the fix for synchronize_rcu_expedited() and friends, but until someone
actually needs to use synchronize_srcu() during this window, this fix
is added churn for no benefit.
Finally, note that Tree SRCU's new srcu_init() function invokes
queue_work() rather than the queue_delayed_work() function that is
invoked post-boot. The reason is that queue_delayed_work() will (as you
would expect) post a timer, and timers have not yet been initialized.
So use of queue_work() avoids the complaints about use of uninitialized
spinlocks that would otherwise result. Besides, some delay is already
provide by the aforementioned fact that the queued work won't actually
be invoked until after the scheduler is up and running.
Requested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2018-08-14 23:45:54 +08:00
|
|
|
if (IS_ENABLED(CONFIG_SRCU))
|
|
|
|
call_srcu(&early_srcu, &shead, test_callback);
|
rcu: Add basic support for kfree_rcu() batching
Recently a discussion about stability and performance of a system
involving a high rate of kfree_rcu() calls surfaced on the list [1]
which led to another discussion how to prepare for this situation.
This patch adds basic batching support for kfree_rcu(). It is "basic"
because we do none of the slab management, dynamic allocation, code
moving or any of the other things, some of which previous attempts did
[2]. These fancier improvements can be follow-up patches and there are
different ideas being discussed in those regards. This is an effort to
start simple, and build up from there. In the future, an extension to
use kfree_bulk and possibly per-slab batching could be done to further
improve performance due to cache-locality and slab-specific bulk free
optimizations. By using an array of pointers, the worker thread
processing the work would need to read lesser data since it does not
need to deal with large rcu_head(s) any longer.
Torture tests follow in the next patch and show improvements of around
5x reduction in number of grace periods on a 16 CPU system. More
details and test data are in that patch.
There is an implication with rcu_barrier() with this patch. Since the
kfree_rcu() calls can be batched, and may not be handed yet to the RCU
machinery in fact, the monitor may not have even run yet to do the
queue_rcu_work(), there seems no easy way of implementing rcu_barrier()
to wait for those kfree_rcu()s that are already made. So this means a
kfree_rcu() followed by an rcu_barrier() does not imply that memory will
be freed once rcu_barrier() returns.
Another implication is higher active memory usage (although not
run-away..) until the kfree_rcu() flooding ends, in comparison to
without batching. More details about this are in the second patch which
adds an rcuperf test.
Finally, in the near future we will get rid of kfree_rcu() special casing
within RCU such as in rcu_do_batch and switch everything to just
batching. Currently we don't do that since timer subsystem is not yet up
and we cannot schedule the kfree_rcu() monitor as the timer subsystem's
lock are not initialized. That would also mean getting rid of
kfree_call_rcu_nobatch() entirely.
[1] http://lore.kernel.org/lkml/20190723035725-mutt-send-email-mst@kernel.org
[2] https://lkml.org/lkml/2017/12/19/824
Cc: kernel-team@android.com
Cc: kernel-team@lge.com
Co-developed-by: Byungchul Park <byungchul.park@lge.com>
Signed-off-by: Byungchul Park <byungchul.park@lge.com>
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
[ paulmck: Applied 0day and Paul Walmsley feedback on ->monitor_todo. ]
[ paulmck: Make it work during early boot. ]
[ paulmck: Add a crude early boot self-test. ]
[ paulmck: Style adjustments and experimental docbook structure header. ]
Link: https://lore.kernel.org/lkml/alpine.DEB.2.21.9999.1908161931110.32497@viisi.sifive.com/T/#me9956f66cb611b95d26ae92700e1d901f46e8c59
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2019-08-06 06:22:27 +08:00
|
|
|
rhp = kmalloc(sizeof(*rhp), GFP_KERNEL);
|
|
|
|
if (!WARN_ON_ONCE(!rhp))
|
|
|
|
kfree_rcu(rhp, rh);
|
2014-09-19 23:32:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void rcu_early_boot_tests(void)
|
|
|
|
{
|
|
|
|
pr_info("Running RCU self tests\n");
|
|
|
|
|
|
|
|
if (rcu_self_test)
|
|
|
|
early_boot_test_call_rcu();
|
rcu: Narrow early boot window of illegal synchronous grace periods
The current preemptible RCU implementation goes through three phases
during bootup. In the first phase, there is only one CPU that is running
with preemption disabled, so that a no-op is a synchronous grace period.
In the second mid-boot phase, the scheduler is running, but RCU has
not yet gotten its kthreads spawned (and, for expedited grace periods,
workqueues are not yet running. During this time, any attempt to do
a synchronous grace period will hang the system (or complain bitterly,
depending). In the third and final phase, RCU is fully operational and
everything works normally.
This has been OK for some time, but there has recently been some
synchronous grace periods showing up during the second mid-boot phase.
This code worked "by accident" for awhile, but started failing as soon
as expedited RCU grace periods switched over to workqueues in commit
8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue").
Note that the code was buggy even before this commit, as it was subject
to failure on real-time systems that forced all expedited grace periods
to run as normal grace periods (for example, using the rcu_normal ksysfs
parameter). The callchain from the failure case is as follows:
early_amd_iommu_init()
|-> acpi_put_table(ivrs_base);
|-> acpi_tb_put_table(table_desc);
|-> acpi_tb_invalidate_table(table_desc);
|-> acpi_tb_release_table(...)
|-> acpi_os_unmap_memory
|-> acpi_os_unmap_iomem
|-> acpi_os_map_cleanup
|-> synchronize_rcu_expedited
The kernel showing this callchain was built with CONFIG_PREEMPT_RCU=y,
which caused the code to try using workqueues before they were
initialized, which did not go well.
This commit therefore reworks RCU to permit synchronous grace periods
to proceed during this mid-boot phase. This commit is therefore a
fix to a regression introduced in v4.9, and is therefore being put
forward post-merge-window in v4.10.
This commit sets a flag from the existing rcu_scheduler_starting()
function which causes all synchronous grace periods to take the expedited
path. The expedited path now checks this flag, using the requesting task
to drive the expedited grace period forward during the mid-boot phase.
Finally, this flag is updated by a core_initcall() function named
rcu_exp_runtime_mode(), which causes the runtime codepaths to be used.
Note that this arrangement assumes that tasks are not sent POSIX signals
(or anything similar) from the time that the first task is spawned
through core_initcall() time.
Fixes: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
Reported-by: "Zheng, Lv" <lv.zheng@intel.com>
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Stan Kain <stan.kain@gmail.com>
Tested-by: Ivan <waffolz@hotmail.com>
Tested-by: Emanuel Castelo <emanuel.castelo@gmail.com>
Tested-by: Bruno Pesavento <bpesavento@infinito.it>
Tested-by: Borislav Petkov <bp@suse.de>
Tested-by: Frederic Bezies <fredbezies@gmail.com>
Cc: <stable@vger.kernel.org> # 4.9.0-
2017-01-10 18:28:26 +08:00
|
|
|
rcu_test_sync_prims();
|
2014-09-19 23:32:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int rcu_verify_early_boot_tests(void)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
int early_boot_test_counter = 0;
|
|
|
|
|
|
|
|
if (rcu_self_test) {
|
|
|
|
early_boot_test_counter++;
|
|
|
|
rcu_barrier();
|
srcu: Make call_srcu() available during very early boot
Event tracing is moving to SRCU in order to take advantage of the fact
that SRCU may be safely used from idle and even offline CPUs. However,
event tracing can invoke call_srcu() very early in the boot process,
even before workqueue_init_early() is invoked (let alone rcu_init()).
Therefore, call_srcu()'s attempts to queue work fail miserably.
This commit therefore detects this situation, and refrains from attempting
to queue work before rcu_init() time, but does everything else that it
would have done, and in addition, adds the srcu_struct to a global list.
The rcu_init() function now invokes a new srcu_init() function, which
is empty if CONFIG_SRCU=n. Otherwise, srcu_init() queues work for
each srcu_struct on the list. This all happens early enough in boot
that there is but a single CPU with interrupts disabled, which allows
synchronization to be dispensed with.
Of course, the queued work won't actually be invoked until after
workqueue_init() is invoked, which happens shortly after the scheduler
is up and running. This means that although call_srcu() may be invoked
any time after per-CPU variables have been set up, there is still a very
narrow window when synchronize_srcu() won't work, and this window
extends from the time that the scheduler starts until the time that
workqueue_init() returns. This can be fixed in a manner similar to
the fix for synchronize_rcu_expedited() and friends, but until someone
actually needs to use synchronize_srcu() during this window, this fix
is added churn for no benefit.
Finally, note that Tree SRCU's new srcu_init() function invokes
queue_work() rather than the queue_delayed_work() function that is
invoked post-boot. The reason is that queue_delayed_work() will (as you
would expect) post a timer, and timers have not yet been initialized.
So use of queue_work() avoids the complaints about use of uninitialized
spinlocks that would otherwise result. Besides, some delay is already
provide by the aforementioned fact that the queued work won't actually
be invoked until after the scheduler is up and running.
Requested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2018-08-14 23:45:54 +08:00
|
|
|
if (IS_ENABLED(CONFIG_SRCU)) {
|
|
|
|
early_boot_test_counter++;
|
|
|
|
srcu_barrier(&early_srcu);
|
|
|
|
}
|
2014-09-19 23:32:29 +08:00
|
|
|
}
|
|
|
|
if (rcu_self_test_counter != early_boot_test_counter) {
|
|
|
|
WARN_ON(1);
|
|
|
|
ret = -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
late_initcall(rcu_verify_early_boot_tests);
|
|
|
|
#else
|
|
|
|
void rcu_early_boot_tests(void) {}
|
|
|
|
#endif /* CONFIG_PROVE_RCU */
|
2017-04-29 01:20:28 +08:00
|
|
|
|
2020-03-03 03:59:20 +08:00
|
|
|
#include "tasks.h"
|
|
|
|
|
2017-04-29 01:20:28 +08:00
|
|
|
#ifndef CONFIG_TINY_RCU
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Print any significant non-default boot-time settings.
|
|
|
|
*/
|
|
|
|
void __init rcupdate_announce_bootup_oddness(void)
|
|
|
|
{
|
|
|
|
if (rcu_normal)
|
|
|
|
pr_info("\tNo expedited grace period (rcu_normal).\n");
|
|
|
|
else if (rcu_normal_after_boot)
|
|
|
|
pr_info("\tNo expedited grace period (rcu_normal_after_boot).\n");
|
|
|
|
else if (rcu_expedited)
|
|
|
|
pr_info("\tAll grace periods are expedited (rcu_expedited).\n");
|
|
|
|
if (rcu_cpu_stall_suppress)
|
|
|
|
pr_info("\tRCU CPU stall warnings suppressed (rcu_cpu_stall_suppress).\n");
|
|
|
|
if (rcu_cpu_stall_timeout != CONFIG_RCU_CPU_STALL_TIMEOUT)
|
|
|
|
pr_info("\tRCU CPU stall warnings timeout set to %d (rcu_cpu_stall_timeout).\n", rcu_cpu_stall_timeout);
|
|
|
|
rcu_tasks_bootup_oddness();
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* #ifndef CONFIG_TINY_RCU */
|