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>
|
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."
|
|
|
|
|
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
|
|
|
*
|
2019-07-17 06:12:22 +08:00
|
|
|
* Returns true if lockdep must be ignored, in which case *ret contains
|
|
|
|
* the best guess described below. Otherwise returns false, in which
|
|
|
|
* case *ret tells the caller nothing and the caller should instead
|
|
|
|
* consult lockdep.
|
|
|
|
*
|
|
|
|
* 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())
|
|
|
|
* then rcu_read_lock_held() sets *ret to false even if the CPU did an
|
|
|
|
* 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()) {
|
|
|
|
*ret = 1;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (!rcu_is_watching()) {
|
|
|
|
*ret = 0;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (!rcu_lockdep_current_cpu_online()) {
|
|
|
|
*ret = 0;
|
|
|
|
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);
|
|
|
|
|
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);
|
2015-02-20 02:51:32 +08:00
|
|
|
}
|
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;
|
|
|
|
struct lockdep_map rcu_lock_map =
|
|
|
|
STATIC_LOCKDEP_MAP_INIT("rcu_read_lock", &rcu_lock_key);
|
|
|
|
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;
|
|
|
|
struct lockdep_map rcu_bh_lock_map =
|
|
|
|
STATIC_LOCKDEP_MAP_INIT("rcu_read_lock_bh", &rcu_bh_lock_key);
|
|
|
|
EXPORT_SYMBOL_GPL(rcu_bh_lock_map);
|
|
|
|
|
|
|
|
static struct lock_class_key rcu_sched_lock_key;
|
|
|
|
struct lockdep_map rcu_sched_lock_map =
|
|
|
|
STATIC_LOCKDEP_MAP_INIT("rcu_read_lock_sched", &rcu_sched_lock_key);
|
|
|
|
EXPORT_SYMBOL_GPL(rcu_sched_lock_map);
|
2010-03-16 08:03:43 +08:00
|
|
|
|
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);
|
|
|
|
|
2013-08-31 13:04:07 +08:00
|
|
|
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);
|
2019-02-13 00:14:37 +08:00
|
|
|
NOKPROBE_SYMBOL(debug_lockdep_rcu_enabled);
|
2010-04-16 03:50:39 +08:00
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
init_rcu_head_on_stack(&rs_array[i].head);
|
|
|
|
init_completion(&rs_array[i].completion);
|
2017-04-29 07:19:07 +08:00
|
|
|
for (j = 0; j < i; j++)
|
|
|
|
if (crcu_array[j] == crcu_array[i])
|
|
|
|
break;
|
|
|
|
if (j == i)
|
|
|
|
(crcu_array[i])(&rs_array[i].head, wakeme_after_rcu);
|
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;
|
|
|
|
if (j == i)
|
|
|
|
wait_for_completion(&rs_array[i].completion);
|
2015-06-11 03:53:06 +08:00
|
|
|
destroy_rcu_head_on_stack(&rs_array[i].head);
|
|
|
|
}
|
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);
|
2012-10-20 03:49:17 +08:00
|
|
|
int rcu_cpu_stall_suppress __read_mostly; /* 1 = 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
|
|
|
|
|
|
|
#ifdef CONFIG_TASKS_RCU
|
|
|
|
|
|
|
|
/*
|
2018-05-15 04:52:27 +08:00
|
|
|
* Simple variant of RCU whose quiescent states are voluntary context
|
|
|
|
* switch, cond_resched_rcu_qs(), user-space execution, and idle.
|
|
|
|
* As such, grace periods can take one good long time. There are no
|
|
|
|
* read-side primitives similar to rcu_read_lock() and rcu_read_unlock()
|
|
|
|
* because this implementation is intended to get the system into a safe
|
|
|
|
* state for some of the manipulations involved in tracing and the like.
|
|
|
|
* Finally, this implementation does not support high call_rcu_tasks()
|
|
|
|
* rates from multiple CPUs. If this is required, per-CPU callback lists
|
|
|
|
* will be needed.
|
2014-06-28 04:42:20 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
/* Global list of callbacks and associated lock. */
|
|
|
|
static struct rcu_head *rcu_tasks_cbs_head;
|
|
|
|
static struct rcu_head **rcu_tasks_cbs_tail = &rcu_tasks_cbs_head;
|
2014-07-29 05:39:25 +08:00
|
|
|
static DECLARE_WAIT_QUEUE_HEAD(rcu_tasks_cbs_wq);
|
2014-06-28 04:42:20 +08:00
|
|
|
static DEFINE_RAW_SPINLOCK(rcu_tasks_cbs_lock);
|
|
|
|
|
2014-08-04 21:10:23 +08:00
|
|
|
/* Track exiting tasks in order to allow them to be waited for. */
|
2017-05-25 23:51:48 +08:00
|
|
|
DEFINE_STATIC_SRCU(tasks_rcu_exit_srcu);
|
2014-08-04 21:10:23 +08:00
|
|
|
|
|
|
|
/* Control stall timeouts. Disable with <= 0, otherwise jiffies till stall. */
|
2017-04-29 01:20:28 +08:00
|
|
|
#define RCU_TASK_STALL_TIMEOUT (HZ * 60 * 10)
|
|
|
|
static int rcu_task_stall_timeout __read_mostly = RCU_TASK_STALL_TIMEOUT;
|
2014-08-04 21:10:23 +08:00
|
|
|
module_param(rcu_task_stall_timeout, int, 0644);
|
|
|
|
|
2016-05-03 02:58:56 +08:00
|
|
|
static struct task_struct *rcu_tasks_kthread_ptr;
|
2014-08-04 22:24:21 +08:00
|
|
|
|
2017-05-03 23:34:57 +08:00
|
|
|
/**
|
|
|
|
* call_rcu_tasks() - Queue an RCU for invocation task-based grace period
|
|
|
|
* @rhp: structure to be used for queueing the RCU updates.
|
|
|
|
* @func: actual callback function to be invoked after the grace period
|
|
|
|
*
|
|
|
|
* The callback function will be invoked some time after a full grace
|
|
|
|
* period elapses, in other words after all currently executing RCU
|
|
|
|
* read-side critical sections have completed. call_rcu_tasks() assumes
|
|
|
|
* that the read-side critical sections end at a voluntary context
|
2018-05-15 04:52:27 +08:00
|
|
|
* switch (not a preemption!), cond_resched_rcu_qs(), entry into idle,
|
|
|
|
* or transition to usermode execution. As such, there are no read-side
|
|
|
|
* primitives analogous to rcu_read_lock() and rcu_read_unlock() because
|
|
|
|
* this primitive is intended to determine that all tasks have passed
|
|
|
|
* through a safe state, not so much for data-strcuture synchronization.
|
2017-05-03 23:34:57 +08:00
|
|
|
*
|
|
|
|
* See the description of call_rcu() for more detailed information on
|
|
|
|
* memory ordering guarantees.
|
2014-08-04 22:24:21 +08:00
|
|
|
*/
|
2015-07-29 13:29:38 +08:00
|
|
|
void call_rcu_tasks(struct rcu_head *rhp, rcu_callback_t func)
|
2014-06-28 04:42:20 +08:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
2014-07-29 05:39:25 +08:00
|
|
|
bool needwake;
|
2014-06-28 04:42:20 +08:00
|
|
|
|
|
|
|
rhp->next = NULL;
|
|
|
|
rhp->func = func;
|
|
|
|
raw_spin_lock_irqsave(&rcu_tasks_cbs_lock, flags);
|
2014-07-29 05:39:25 +08:00
|
|
|
needwake = !rcu_tasks_cbs_head;
|
2014-06-28 04:42:20 +08:00
|
|
|
*rcu_tasks_cbs_tail = rhp;
|
|
|
|
rcu_tasks_cbs_tail = &rhp->next;
|
|
|
|
raw_spin_unlock_irqrestore(&rcu_tasks_cbs_lock, flags);
|
2016-05-03 02:58:56 +08:00
|
|
|
/* We can't create the thread unless interrupts are enabled. */
|
2017-08-12 03:37:07 +08:00
|
|
|
if (needwake && READ_ONCE(rcu_tasks_kthread_ptr))
|
2014-07-29 05:39:25 +08:00
|
|
|
wake_up(&rcu_tasks_cbs_wq);
|
2014-06-28 04:42:20 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(call_rcu_tasks);
|
|
|
|
|
2014-07-02 03:22:23 +08:00
|
|
|
/**
|
|
|
|
* synchronize_rcu_tasks - wait until an rcu-tasks grace period has elapsed.
|
|
|
|
*
|
|
|
|
* Control will return to the caller some time after a full rcu-tasks
|
|
|
|
* grace period has elapsed, in other words after all currently
|
|
|
|
* executing rcu-tasks read-side critical sections have elapsed. These
|
|
|
|
* read-side critical sections are delimited by calls to schedule(),
|
2018-03-03 08:35:27 +08:00
|
|
|
* cond_resched_tasks_rcu_qs(), idle execution, userspace execution, calls
|
2014-07-02 03:22:23 +08:00
|
|
|
* to synchronize_rcu_tasks(), and (in theory, anyway) cond_resched().
|
|
|
|
*
|
|
|
|
* This is a very specialized primitive, intended only for a few uses in
|
|
|
|
* tracing and other situations requiring manipulation of function
|
|
|
|
* preambles and profiling hooks. The synchronize_rcu_tasks() function
|
|
|
|
* is not (yet) intended for heavy use from multiple CPUs.
|
|
|
|
*
|
|
|
|
* Note that this guarantee implies further memory-ordering guarantees.
|
|
|
|
* On systems with more than one CPU, when synchronize_rcu_tasks() returns,
|
|
|
|
* each CPU is guaranteed to have executed a full memory barrier since the
|
|
|
|
* end of its last RCU-tasks read-side critical section whose beginning
|
|
|
|
* preceded the call to synchronize_rcu_tasks(). In addition, each CPU
|
|
|
|
* having an RCU-tasks read-side critical section that extends beyond
|
|
|
|
* the return from synchronize_rcu_tasks() is guaranteed to have executed
|
|
|
|
* a full memory barrier after the beginning of synchronize_rcu_tasks()
|
|
|
|
* and before the beginning of that RCU-tasks read-side critical section.
|
|
|
|
* Note that these guarantees include CPUs that are offline, idle, or
|
|
|
|
* executing in user mode, as well as CPUs that are executing in the kernel.
|
|
|
|
*
|
|
|
|
* Furthermore, if CPU A invoked synchronize_rcu_tasks(), which returned
|
|
|
|
* to its caller on CPU B, then both CPU A and CPU B are guaranteed
|
|
|
|
* to have executed a full memory barrier during the execution of
|
|
|
|
* synchronize_rcu_tasks() -- even if CPU A and CPU B are the same CPU
|
|
|
|
* (but again only if the system has more than one CPU).
|
|
|
|
*/
|
|
|
|
void synchronize_rcu_tasks(void)
|
|
|
|
{
|
|
|
|
/* Complain if the scheduler has not started. */
|
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_LOCKDEP_WARN(rcu_scheduler_active == RCU_SCHEDULER_INACTIVE,
|
2015-06-19 06:50:02 +08:00
|
|
|
"synchronize_rcu_tasks called too soon");
|
2014-07-02 03:22:23 +08:00
|
|
|
|
|
|
|
/* Wait for the grace period. */
|
|
|
|
wait_rcu_gp(call_rcu_tasks);
|
|
|
|
}
|
2014-07-03 09:17:19 +08:00
|
|
|
EXPORT_SYMBOL_GPL(synchronize_rcu_tasks);
|
2014-07-02 03:22:23 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* rcu_barrier_tasks - Wait for in-flight call_rcu_tasks() callbacks.
|
|
|
|
*
|
|
|
|
* Although the current implementation is guaranteed to wait, it is not
|
|
|
|
* obligated to, for example, if there are no pending callbacks.
|
|
|
|
*/
|
|
|
|
void rcu_barrier_tasks(void)
|
|
|
|
{
|
|
|
|
/* There is only one callback queue, so this is easy. ;-) */
|
|
|
|
synchronize_rcu_tasks();
|
|
|
|
}
|
2014-07-03 09:17:19 +08:00
|
|
|
EXPORT_SYMBOL_GPL(rcu_barrier_tasks);
|
2014-07-02 03:22:23 +08:00
|
|
|
|
2014-07-02 09:16:30 +08:00
|
|
|
/* See if tasks are still holding out, complain if so. */
|
|
|
|
static void check_holdout_task(struct task_struct *t,
|
|
|
|
bool needreport, bool *firstreport)
|
2014-06-28 04:42:20 +08:00
|
|
|
{
|
2014-08-11 10:47:12 +08:00
|
|
|
int cpu;
|
|
|
|
|
2015-03-04 06:57:58 +08:00
|
|
|
if (!READ_ONCE(t->rcu_tasks_holdout) ||
|
|
|
|
t->rcu_tasks_nvcsw != READ_ONCE(t->nvcsw) ||
|
|
|
|
!READ_ONCE(t->on_rq) ||
|
2014-08-05 08:43:50 +08:00
|
|
|
(IS_ENABLED(CONFIG_NO_HZ_FULL) &&
|
|
|
|
!is_idle_task(t) && t->rcu_tasks_idle_cpu >= 0)) {
|
2015-03-04 06:57:58 +08:00
|
|
|
WRITE_ONCE(t->rcu_tasks_holdout, false);
|
2014-08-05 20:10:24 +08:00
|
|
|
list_del_init(&t->rcu_tasks_holdout_list);
|
2014-06-28 04:42:20 +08:00
|
|
|
put_task_struct(t);
|
2014-07-02 09:16:30 +08:00
|
|
|
return;
|
2014-06-28 04:42:20 +08:00
|
|
|
}
|
2017-04-12 06:50:41 +08:00
|
|
|
rcu_request_urgent_qs_task(t);
|
2014-07-02 09:16:30 +08:00
|
|
|
if (!needreport)
|
|
|
|
return;
|
|
|
|
if (*firstreport) {
|
|
|
|
pr_err("INFO: rcu_tasks detected stalls on tasks:\n");
|
|
|
|
*firstreport = false;
|
|
|
|
}
|
2014-08-11 10:47:12 +08:00
|
|
|
cpu = task_cpu(t);
|
|
|
|
pr_alert("%p: %c%c nvcsw: %lu/%lu holdout: %d idle_cpu: %d/%d\n",
|
|
|
|
t, ".I"[is_idle_task(t)],
|
|
|
|
"N."[cpu < 0 || !tick_nohz_full_cpu(cpu)],
|
|
|
|
t->rcu_tasks_nvcsw, t->nvcsw, t->rcu_tasks_holdout,
|
|
|
|
t->rcu_tasks_idle_cpu, cpu);
|
2014-07-02 09:16:30 +08:00
|
|
|
sched_show_task(t);
|
2014-06-28 04:42:20 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* RCU-tasks kthread that detects grace periods and invokes callbacks. */
|
|
|
|
static int __noreturn rcu_tasks_kthread(void *arg)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
struct task_struct *g, *t;
|
2014-07-02 09:16:30 +08:00
|
|
|
unsigned long lastreport;
|
2014-06-28 04:42:20 +08:00
|
|
|
struct rcu_head *list;
|
|
|
|
struct rcu_head *next;
|
|
|
|
LIST_HEAD(rcu_tasks_holdouts);
|
2018-05-25 06:49:46 +08:00
|
|
|
int fract;
|
2014-06-28 04:42:20 +08:00
|
|
|
|
2014-10-28 07:04:35 +08:00
|
|
|
/* Run on housekeeping CPUs by default. Sysadm can move if desired. */
|
2017-10-27 10:42:35 +08:00
|
|
|
housekeeping_affine(current, HK_FLAG_RCU);
|
2014-06-28 04:42:20 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Each pass through the following loop makes one check for
|
|
|
|
* newly arrived callbacks, and, if there are some, waits for
|
|
|
|
* one RCU-tasks grace period and then invokes the callbacks.
|
|
|
|
* This loop is terminated by the system going down. ;-)
|
|
|
|
*/
|
|
|
|
for (;;) {
|
|
|
|
|
|
|
|
/* Pick up any new callbacks. */
|
|
|
|
raw_spin_lock_irqsave(&rcu_tasks_cbs_lock, flags);
|
|
|
|
list = rcu_tasks_cbs_head;
|
|
|
|
rcu_tasks_cbs_head = NULL;
|
|
|
|
rcu_tasks_cbs_tail = &rcu_tasks_cbs_head;
|
|
|
|
raw_spin_unlock_irqrestore(&rcu_tasks_cbs_lock, flags);
|
|
|
|
|
|
|
|
/* If there were none, wait a bit and start over. */
|
|
|
|
if (!list) {
|
2014-07-29 05:39:25 +08:00
|
|
|
wait_event_interruptible(rcu_tasks_cbs_wq,
|
|
|
|
rcu_tasks_cbs_head);
|
|
|
|
if (!rcu_tasks_cbs_head) {
|
|
|
|
WARN_ON(signal_pending(current));
|
|
|
|
schedule_timeout_interruptible(HZ/10);
|
|
|
|
}
|
2014-06-28 04:42:20 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Wait for all pre-existing t->on_rq and t->nvcsw
|
2018-07-09 01:58:37 +08:00
|
|
|
* transitions to complete. Invoking synchronize_rcu()
|
2014-06-28 04:42:20 +08:00
|
|
|
* suffices because all these transitions occur with
|
2018-07-09 01:58:37 +08:00
|
|
|
* interrupts disabled. Without this synchronize_rcu(),
|
2014-06-28 04:42:20 +08:00
|
|
|
* a read-side critical section that started before the
|
|
|
|
* grace period might be incorrectly seen as having started
|
|
|
|
* after the grace period.
|
|
|
|
*
|
2018-07-09 01:58:37 +08:00
|
|
|
* This synchronize_rcu() also dispenses with the
|
2014-06-28 04:42:20 +08:00
|
|
|
* need for a memory barrier on the first store to
|
|
|
|
* ->rcu_tasks_holdout, as it forces the store to happen
|
|
|
|
* after the beginning of the grace period.
|
|
|
|
*/
|
2018-07-09 01:58:37 +08:00
|
|
|
synchronize_rcu();
|
2014-06-28 04:42:20 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* There were callbacks, so we need to wait for an
|
|
|
|
* RCU-tasks grace period. Start off by scanning
|
|
|
|
* the task list for tasks that are not already
|
|
|
|
* voluntarily blocked. Mark these tasks and make
|
|
|
|
* a list of them in rcu_tasks_holdouts.
|
|
|
|
*/
|
|
|
|
rcu_read_lock();
|
|
|
|
for_each_process_thread(g, t) {
|
2015-03-04 06:57:58 +08:00
|
|
|
if (t != current && READ_ONCE(t->on_rq) &&
|
2014-06-28 04:42:20 +08:00
|
|
|
!is_idle_task(t)) {
|
|
|
|
get_task_struct(t);
|
2015-03-04 06:57:58 +08:00
|
|
|
t->rcu_tasks_nvcsw = READ_ONCE(t->nvcsw);
|
|
|
|
WRITE_ONCE(t->rcu_tasks_holdout, true);
|
2014-06-28 04:42:20 +08:00
|
|
|
list_add(&t->rcu_tasks_holdout_list,
|
|
|
|
&rcu_tasks_holdouts);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
2014-08-04 21:10:23 +08:00
|
|
|
/*
|
|
|
|
* Wait for tasks that are in the process of exiting.
|
|
|
|
* This does only part of the job, ensuring that all
|
|
|
|
* tasks that were previously exiting reach the point
|
|
|
|
* where they have disabled preemption, allowing the
|
2018-07-09 01:58:37 +08:00
|
|
|
* later synchronize_rcu() to finish the job.
|
2014-08-04 21:10:23 +08:00
|
|
|
*/
|
|
|
|
synchronize_srcu(&tasks_rcu_exit_srcu);
|
|
|
|
|
2014-06-28 04:42:20 +08:00
|
|
|
/*
|
|
|
|
* Each pass through the following loop scans the list
|
|
|
|
* of holdout tasks, removing any that are no longer
|
|
|
|
* holdouts. When the list is empty, we are done.
|
|
|
|
*/
|
2014-07-02 09:16:30 +08:00
|
|
|
lastreport = jiffies;
|
2018-05-25 06:49:46 +08:00
|
|
|
|
|
|
|
/* Start off with HZ/10 wait and slowly back off to 1 HZ wait*/
|
|
|
|
fract = 10;
|
|
|
|
|
|
|
|
for (;;) {
|
2014-07-02 09:16:30 +08:00
|
|
|
bool firstreport;
|
|
|
|
bool needreport;
|
|
|
|
int rtst;
|
2014-08-05 20:10:24 +08:00
|
|
|
struct task_struct *t1;
|
2014-07-02 09:16:30 +08:00
|
|
|
|
2018-05-25 06:49:46 +08:00
|
|
|
if (list_empty(&rcu_tasks_holdouts))
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* Slowly back off waiting for holdouts */
|
|
|
|
schedule_timeout_interruptible(HZ/fract);
|
|
|
|
|
|
|
|
if (fract > 1)
|
|
|
|
fract--;
|
|
|
|
|
2015-03-04 06:57:58 +08:00
|
|
|
rtst = READ_ONCE(rcu_task_stall_timeout);
|
2014-07-02 09:16:30 +08:00
|
|
|
needreport = rtst > 0 &&
|
|
|
|
time_after(jiffies, lastreport + rtst);
|
|
|
|
if (needreport)
|
|
|
|
lastreport = jiffies;
|
|
|
|
firstreport = true;
|
2014-06-28 04:42:20 +08:00
|
|
|
WARN_ON(signal_pending(current));
|
2014-08-05 20:10:24 +08:00
|
|
|
list_for_each_entry_safe(t, t1, &rcu_tasks_holdouts,
|
|
|
|
rcu_tasks_holdout_list) {
|
2014-07-02 09:16:30 +08:00
|
|
|
check_holdout_task(t, needreport, &firstreport);
|
2014-08-05 20:10:24 +08:00
|
|
|
cond_resched();
|
|
|
|
}
|
2014-06-28 04:42:20 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Because ->on_rq and ->nvcsw are not guaranteed
|
|
|
|
* to have a full memory barriers prior to them in the
|
|
|
|
* schedule() path, memory reordering on other CPUs could
|
|
|
|
* cause their RCU-tasks read-side critical sections to
|
|
|
|
* extend past the end of the grace period. However,
|
|
|
|
* because these ->nvcsw updates are carried out with
|
2018-07-09 01:58:37 +08:00
|
|
|
* interrupts disabled, we can use synchronize_rcu()
|
2014-06-28 04:42:20 +08:00
|
|
|
* to force the needed ordering on all such CPUs.
|
|
|
|
*
|
2018-07-09 01:58:37 +08:00
|
|
|
* This synchronize_rcu() also confines all
|
2014-06-28 04:42:20 +08:00
|
|
|
* ->rcu_tasks_holdout accesses to be within the grace
|
|
|
|
* period, avoiding the need for memory barriers for
|
|
|
|
* ->rcu_tasks_holdout accesses.
|
2014-08-04 21:10:23 +08:00
|
|
|
*
|
2018-07-09 01:58:37 +08:00
|
|
|
* In addition, this synchronize_rcu() waits for exiting
|
2014-08-04 21:10:23 +08:00
|
|
|
* tasks to complete their final preempt_disable() region
|
|
|
|
* of execution, cleaning up after the synchronize_srcu()
|
|
|
|
* above.
|
2014-06-28 04:42:20 +08:00
|
|
|
*/
|
2018-07-09 01:58:37 +08:00
|
|
|
synchronize_rcu();
|
2014-06-28 04:42:20 +08:00
|
|
|
|
|
|
|
/* Invoke the callbacks. */
|
|
|
|
while (list) {
|
|
|
|
next = list->next;
|
|
|
|
local_bh_disable();
|
|
|
|
list->func(list);
|
|
|
|
local_bh_enable();
|
|
|
|
list = next;
|
|
|
|
cond_resched();
|
|
|
|
}
|
2018-05-25 06:58:16 +08:00
|
|
|
/* Paranoid sleep to keep this from entering a tight loop */
|
2014-07-29 05:39:25 +08:00
|
|
|
schedule_timeout_uninterruptible(HZ/10);
|
2014-06-28 04:42:20 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-08-12 03:37:07 +08:00
|
|
|
/* Spawn rcu_tasks_kthread() at core_initcall() time. */
|
|
|
|
static int __init rcu_spawn_tasks_kthread(void)
|
2014-06-28 04:42:20 +08:00
|
|
|
{
|
2014-08-04 22:24:21 +08:00
|
|
|
struct task_struct *t;
|
2014-06-28 04:42:20 +08:00
|
|
|
|
|
|
|
t = kthread_run(rcu_tasks_kthread, NULL, "rcu_tasks_kthread");
|
2018-10-22 23:33:06 +08:00
|
|
|
if (WARN_ONCE(IS_ERR(t), "%s: Could not start Tasks-RCU grace-period kthread, OOM is now expected behavior\n", __func__))
|
|
|
|
return 0;
|
2014-08-04 22:24:21 +08:00
|
|
|
smp_mb(); /* Ensure others see full kthread. */
|
2015-03-04 06:57:58 +08:00
|
|
|
WRITE_ONCE(rcu_tasks_kthread_ptr, t);
|
2017-08-12 03:37:07 +08:00
|
|
|
return 0;
|
2014-06-28 04:42:20 +08:00
|
|
|
}
|
2017-08-12 03:37:07 +08:00
|
|
|
core_initcall(rcu_spawn_tasks_kthread);
|
2014-06-28 04:42:20 +08:00
|
|
|
|
2017-05-25 23:51:48 +08:00
|
|
|
/* Do the srcu_read_lock() for the above synchronize_srcu(). */
|
|
|
|
void exit_tasks_rcu_start(void)
|
|
|
|
{
|
|
|
|
preempt_disable();
|
|
|
|
current->rcu_tasks_idx = __srcu_read_lock(&tasks_rcu_exit_srcu);
|
|
|
|
preempt_enable();
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Do the srcu_read_unlock() for the above synchronize_srcu(). */
|
|
|
|
void exit_tasks_rcu_finish(void)
|
|
|
|
{
|
|
|
|
preempt_disable();
|
|
|
|
__srcu_read_unlock(&tasks_rcu_exit_srcu, current->rcu_tasks_idx);
|
|
|
|
preempt_enable();
|
|
|
|
}
|
|
|
|
|
2014-06-28 04:42:20 +08:00
|
|
|
#endif /* #ifdef CONFIG_TASKS_RCU */
|
2014-09-19 23:32:29 +08:00
|
|
|
|
2017-04-29 01:20:28 +08:00
|
|
|
#ifndef CONFIG_TINY_RCU
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Print any non-default Tasks RCU settings.
|
|
|
|
*/
|
|
|
|
static void __init rcu_tasks_bootup_oddness(void)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_TASKS_RCU
|
|
|
|
if (rcu_task_stall_timeout != RCU_TASK_STALL_TIMEOUT)
|
|
|
|
pr_info("\tTasks-RCU CPU stall warnings timeout set to %d (rcu_task_stall_timeout).\n", rcu_task_stall_timeout);
|
|
|
|
else
|
|
|
|
pr_info("\tTasks RCU enabled.\n");
|
|
|
|
#endif /* #ifdef CONFIG_TASKS_RCU */
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* #ifndef CONFIG_TINY_RCU */
|
|
|
|
|
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
|
|
|
|
|
|
|
#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 */
|