Merge branch 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

of the level of loading on the system.

</p><p>RCU updaters wait for normal grace periods by registering

RCU callbacks, either directly via <tt>call_rcu()</tt> and

friends (namely <tt>call_rcu_bh()</tt> and <tt>call_rcu_sched()</tt>),

RCU callbacks, either directly via <tt>call_rcu()</tt>

or indirectly via <tt>synchronize_rcu()</tt> and friends.

RCU callbacks are represented by <tt>rcu_head</tt> structures,

which are queued on <tt>rcu_data</tt> structures while they are

RCU-preempt Expedited Grace Periods</a></h2>

<p>

<tt>CONFIG_PREEMPT=y</tt> kernels implement RCU-preempt.

The overall flow of the handling of a given CPU by an RCU-preempt

expedited grace period is shown in the following diagram:

RCU-sched Expedited Grace Periods</a></h2>

<p>

<tt>CONFIG_PREEMPT=n</tt> kernels implement RCU-sched.

The overall flow of the handling of a given CPU by an RCU-sched

expedited grace period is shown in the following diagram:

<p>

As with RCU-preempt, RCU-sched's

<tt>synchronize_sched_expedited()</tt> ignores offline and

<tt>synchronize_rcu_expedited()</tt> ignores offline and

idle CPUs, again because they are in remotely detectable

quiescent states.

However, because the

period is guaranteed to see the effects of all accesses following the end

of that grace period that are within RCU read-side critical sections.

<p>This guarantee is particularly pervasive for <tt>synchronize_sched()</tt>,

for which RCU-sched read-side critical sections include any region

<p>Note well that RCU-sched read-side critical sections include any region

of code for which preemption is disabled.

Given that each individual machine instruction can be thought of as

an extremely small region of preemption-disabled code, one can think of

<tt>synchronize_sched()</tt> as <tt>smp_mb()</tt> on steroids.

<tt>synchronize_rcu()</tt> as <tt>smp_mb()</tt> on steroids.

<p>RCU updaters use this guarantee by splitting their updates into

two phases, one of which is executed before the grace period and

up any data structures used by the old NMI handler until execution

of it completes on all other CPUs.

One way to accomplish this is via synchronize_sched(), perhaps as

One way to accomplish this is via synchronize_rcu(), perhaps as

follows:

	unset_nmi_callback();

	synchronize_sched();

	synchronize_rcu();

	kfree(my_nmi_data);

This works because synchronize_sched() blocks until all CPUs complete

any preemption-disabled segments of code that they were executing.

Since NMI handlers disable preemption, synchronize_sched() is guaranteed

This works because (as of v4.20) synchronize_rcu() blocks until all

CPUs complete any preemption-disabled segments of code that they were

executing.

Since NMI handlers disable preemption, synchronize_rcu() is guaranteed

not to return until all ongoing NMI handlers exit.  It is therefore safe

to free up the handler's data as soon as synchronize_sched() returns.

to free up the handler's data as soon as synchronize_rcu() returns.

Important note: for this to work, the architecture in question must

invoke nmi_enter() and nmi_exit() on NMI entry and exit, respectively.

infrastructure -must- respect grace periods, and -must- invoke callbacks

from a known environment in which no locks are held.

It -is- safe for synchronize_sched() and synchronize_rcu_bh() to return

immediately on an UP system.  It is also safe for synchronize_rcu()

to return immediately on UP systems, except when running preemptable

RCU.

Note that it -is- safe for synchronize_rcu() to return immediately on

UP systems, including !PREEMPT SMP builds running on UP systems.

Quick Quiz #3: Why can't synchronize_rcu() return immediately on

	UP systems running preemptable RCU?