Merge tag 'rcu.2024.07.12a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu

``atomic_add_return()`` read-modify-write atomic operation that

is invoked within ``rcu_dynticks_eqs_enter()`` at idle-entry

time and within ``rcu_dynticks_eqs_exit()`` at idle-exit time.

The grace-period kthread invokes ``rcu_dynticks_snap()`` and

``rcu_dynticks_in_eqs_since()`` (both of which invoke

an ``atomic_add_return()`` of zero) to detect idle CPUs.

The grace-period kthread invokes first ``ct_dynticks_cpu_acquire()``

(preceded by a full memory barrier) and ``rcu_dynticks_in_eqs_since()``

(both of which rely on acquire semantics) to detect idle CPUs.

+-----------------------------------------------------------------------+

| **Quick Quiz**:                                                       |

#. `Sched Flavor (Historical)`_

#. `Sleepable RCU`_

#. `Tasks RCU`_

#. `Tasks Trace RCU`_

Bottom-Half Flavor (Historical)

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

is, calls to schedule(), cond_resched(), and

synchronize_rcu_tasks(). In addition, transitions to and from

userspace execution also delimit tasks-RCU read-side critical sections.

Idle tasks are ignored by Tasks RCU, and Tasks Rude RCU may be used to

interact with them.

Note well that involuntary context switches are *not* Tasks-RCU quiescent

states.  After all, in preemptible kernels, a task executing code in a

trampoline might be preempted.  In this case, the Tasks-RCU grace period

clearly cannot end until that task resumes and its execution leaves that

trampoline.  This means, among other things, that cond_resched() does

not provide a Tasks RCU quiescent state.  (Instead, use rcu_softirq_qs()

from softirq or rcu_tasks_classic_qs() otherwise.)

The tasks-RCU API is quite compact, consisting only of

call_rcu_tasks(), synchronize_rcu_tasks(), and

workloads that don't want their ``nohz_full`` CPUs receiving IPIs and

by battery-powered systems that don't want their idle CPUs to be awakened.

Once kernel entry/exit and deep-idle functions have been properly tagged

``noinstr``, Tasks RCU can start paying attention to idle tasks (except

those that are idle from RCU's perspective) and then Tasks Rude RCU can

be removed from the kernel.

The tasks-rude-RCU API is also reader-marking-free and thus quite compact,

consisting of call_rcu_tasks_rude(), synchronize_rcu_tasks_rude(),

and rcu_barrier_tasks_rude().

^^^^^^^^^^^^^^^^^^^^

	void rcu_assign_pointer(p, typeof(p) v);

	Yes, rcu_assign_pointer() **is** implemented as a macro, though it

	would be cool to be able to declare a function in this manner.

	(Compiler experts will no doubt disagree.)

	Yes, rcu_assign_pointer() **is** implemented as a macro, though

	it would be cool to be able to declare a function in this manner.

	(And there has been some discussion of adding overloaded functions

	to the C language, so who knows?)

	The updater uses this spatial macro to assign a new value to an

	RCU-protected pointer, in order to safely communicate the change

	in value from the updater to the reader.  This is a spatial (as

	opposed to temporal) macro.  It does not evaluate to an rvalue,

	but it does execute any memory-barrier instructions required

	for a given CPU architecture.  Its ordering properties are that

	of a store-release operation.

	Perhaps just as important, it serves to document (1) which

	pointers are protected by RCU and (2) the point at which a

	given structure becomes accessible to other CPUs.  That said,

	but it does provide any compiler directives and memory-barrier

	instructions required for a given compile or CPU architecture.

	Its ordering properties are that of a store-release operation,

	that is, any prior loads and stores required to initialize the

	structure are ordered before the store that publishes the pointer

	to that structure.

	Perhaps just as important, rcu_assign_pointer() serves to document

	(1) which pointers are protected by RCU and (2) the point at which

	a given structure becomes accessible to other CPUs.  That said,

	rcu_assign_pointer() is most frequently used indirectly, via

	the _rcu list-manipulation primitives such as list_add_rcu().

	executes any needed memory-barrier instructions for a given

	CPU architecture.  Currently, only Alpha needs memory barriers

	within rcu_dereference() -- on other CPUs, it compiles to a

	volatile load.

	volatile load.	However, no mainstream C compilers respect

	address dependencies, so rcu_dereference() uses volatile casts,

	which, in combination with the coding guidelines listed in

	rcu_dereference.rst, prevent current compilers from breaking

	these dependencies.

	Common coding practice uses rcu_dereference() to copy an

	RCU-protected pointer to a local variable, then dereferences

			the ->nocb_bypass queue.  The definition of "too

			many" is supplied by this kernel boot parameter.

	rcutree.nohz_full_patience_delay= [KNL]

			On callback-offloaded (rcu_nocbs) CPUs, avoid

			disturbing RCU unless the grace period has

			reached the specified age in milliseconds.

			Defaults to zero.  Large values will be capped

			at five seconds.  All values will be rounded down

			to the nearest value representable by jiffies.

	rcutree.qhimark= [KNL]

			Set threshold of queued RCU callbacks beyond which

			batch limiting is disabled.

M:	Joel Fernandes <joel@joelfernandes.org>

M:	Josh Triplett <josh@joshtriplett.org>

M:	Boqun Feng <boqun.feng@gmail.com>

M:	Uladzislau Rezki <urezki@gmail.com>

R:	Steven Rostedt <rostedt@goodmis.org>

R:	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

R:	Lai Jiangshan <jiangshanlai@gmail.com>