Merge branches 'cpuinfo.2020.11.06a', 'doc.2020.11.06a', 'fixes.2020.11.19b',...

to allow the various kernel subsystems (including RCU) to respond

appropriately to a given CPU-hotplug operation. Most RCU operations may

be invoked from CPU-hotplug notifiers, including even synchronous

grace-period operations such as ``synchronize_rcu()`` and

``synchronize_rcu_expedited()``.

However, all-callback-wait operations such as ``rcu_barrier()`` are also

not supported, due to the fact that there are phases of CPU-hotplug

operations where the outgoing CPU's callbacks will not be invoked until

after the CPU-hotplug operation ends, which could also result in

deadlock. Furthermore, ``rcu_barrier()`` blocks CPU-hotplug operations

during its execution, which results in another type of deadlock when

invoked from a CPU-hotplug notifier.

grace-period operations such as (``synchronize_rcu()`` and

``synchronize_rcu_expedited()``).  However, these synchronous operations

do block and therefore cannot be invoked from notifiers that execute via

``stop_machine()``, specifically those between the ``CPUHP_AP_OFFLINE``

and ``CPUHP_AP_ONLINE`` states.

In addition, all-callback-wait operations such as ``rcu_barrier()`` may

not be invoked from any CPU-hotplug notifier.  This restriction is due

to the fact that there are phases of CPU-hotplug operations where the

outgoing CPU's callbacks will not be invoked until after the CPU-hotplug

operation ends, which could also result in deadlock. Furthermore,

``rcu_barrier()`` blocks CPU-hotplug operations during its execution,

which results in another type of deadlock when invoked from a CPU-hotplug

notifier.

Finally, RCU must avoid deadlocks due to interaction between hotplug,

timers and grace period processing. It does so by maintaining its own set

of books that duplicate the centrally maintained ``cpu_online_mask``,

and also by reporting quiescent states explicitly when a CPU goes

offline.  This explicit reporting of quiescent states avoids any need

for the force-quiescent-state loop (FQS) to report quiescent states for

offline CPUs.  However, as a debugging measure, the FQS loop does splat

if offline CPUs block an RCU grace period for too long.

An offline CPU's quiescent state will be reported either:

1.  As the CPU goes offline using RCU's hotplug notifier (``rcu_report_dead()``).

2.  When grace period initialization (``rcu_gp_init()``) detects a

    race either with CPU offlining or with a task unblocking on a leaf

    ``rcu_node`` structure whose CPUs are all offline.

The CPU-online path (``rcu_cpu_starting()``) should never need to report

a quiescent state for an offline CPU.  However, as a debugging measure,

it does emit a warning if a quiescent state was not already reported

for that CPU.

During the checking/modification of RCU's hotplug bookkeeping, the

corresponding CPU's leaf node lock is held. This avoids race conditions

between RCU's hotplug notifier hooks, the grace period initialization

code, and the FQS loop, all of which refer to or modify this bookkeeping.

Scheduler and RCU

~~~~~~~~~~~~~~~~~

	shared between readers and updaters.  Additional primitives

	are provided for this case, as discussed in lockdep.txt.

	One exception to this rule is when data is only ever added to

	the linked data structure, and is never removed during any

	time that readers might be accessing that structure.  In such

	cases, READ_ONCE() may be used in place of rcu_dereference()

	and the read-side markers (rcu_read_lock() and rcu_read_unlock(),

	for example) may be omitted.

10.	Conversely, if you are in an RCU read-side critical section,

	and you don't hold the appropriate update-side lock, you -must-

	use the "_rcu()" variants of the list macros.  Failing to do so

	for an example where the compiler can in fact deduce the exact

	value of the pointer, and thus cause misordering.

-	In the special case where data is added but is never removed

	while readers are accessing the structure, READ_ONCE() may be used

	instead of rcu_dereference().  In this case, use of READ_ONCE()

	takes on the role of the lockless_dereference() primitive that

	was removed in v4.15.

-	You are only permitted to use rcu_dereference on pointer values.

	The compiler simply knows too much about integral values to

	trust it to carry dependencies through integer operations.

In such cases, one uses call_rcu() rather than synchronize_rcu().

The call_rcu() API is as follows::

	void call_rcu(struct rcu_head * head,

		      void (*func)(struct rcu_head *head));

	void call_rcu(struct rcu_head *head, rcu_callback_t func);

This function invokes func(head) after a grace period has elapsed.

This invocation might happen from either softirq or process context,

	if (!use_intel() || mtrr_aps_delayed_init)

		return;

	rcu_cpu_starting(smp_processor_id());

	/*

	 * Ideally we should hold mtrr_mutex here to avoid mtrr entries

	 * changed, but this routine will be called in cpu boot time,