Merge tag 'rcu.6.4.april5.2023.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux

Again, only one request in a given batch need actually carry out a

grace-period operation, which means there must be an efficient way to

identify which of many concurrent reqeusts will initiate the grace

identify which of many concurrent requests will initiate the grace

period, and that there be an efficient way for the remaining requests to

wait for that grace period to complete. However, that is the topic of

the next section.

In earlier implementations, the task requesting the expedited grace

period also drove it to completion. This straightforward approach had

the disadvantage of needing to account for POSIX signals sent to user

tasks, so more recent implemementations use the Linux kernel's

tasks, so more recent implementations use the Linux kernel's

workqueues (see Documentation/core-api/workqueue.rst).

The requesting task still does counter snapshotting and funnel-lock

initialized, which does not happen until some time after the scheduler

spawns the first task. Given that there are parts of the kernel that

really do want to execute grace periods during this mid-boot “dead

zone”, expedited grace periods must do something else during thie time.

zone”, expedited grace periods must do something else during this time.

What they do is to fall back to the old practice of requiring that the

requesting task drive the expedited grace period, as was the case before

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

The approach must be extended to handle one final case, that of waking a

task blocked in ``synchronize_rcu()``. This task might be affinitied to

task blocked in ``synchronize_rcu()``. This task might be affined to

a CPU that is not yet aware that the grace period has ended, and thus

might not yet be subject to the grace period's memory ordering.

Therefore, there is an ``smp_mb()`` after the return from

In 2012, Josh Triplett received his Ph.D. with his dissertation

covering RCU-protected resizable hash tables and the relationship

between memory barriers and read-side traversal order:  If the updater

is making changes in the opposite direction from the read-side traveral

is making changes in the opposite direction from the read-side traversal

order, the updater need only execute a memory-barrier instruction,

but if in the same direction, the updater needs to wait for a grace

period between the individual updates [JoshTriplettPhD].  Also in 2012,

[Viewed September 5, 2005]"

,annotation={

	First posting showing how RCU can be safely adapted for

	preemptable RCU read side critical sections.

	preemptible RCU read side critical sections.

}

}

\url{https://lore.kernel.org/r/20070910183004.GA3299@linux.vnet.ibm.com}

[Viewed October 25, 2007]"

,annotation={

	Final patch for preemptable RCU to -rt.  (Later patches were

	Final patch for preemptible RCU to -rt.  (Later patches were

	to mainline, eventually incorporated.)

}

}

\url{https://lore.kernel.org/r/20090724001429.GA17374@linux.vnet.ibm.com}

[Viewed August 15, 2009]"

,annotation={

	First posting of simple and fast preemptable RCU.

	First posting of simple and fast preemptible RCU.

}

}

	RCU-protected hash tables, barriers vs. read-side traversal order.

	.

	If the updater is making changes in the opposite direction from

	the read-side traveral order, the updater need only execute a

	the read-side traversal order, the updater need only execute a

	memory-barrier instruction, but if in the same direction, the

	updater needs to wait for a grace period between the individual

	updates.

Quick Quiz #3:

	Why can't synchronize_rcu() return immediately on UP systems running

	preemptable RCU?

	preemptible RCU?

.. _answer_quick_quiz_up:

Answer to Quick Quiz #3:

	Why can't synchronize_rcu() return immediately on UP systems

	running preemptable RCU?

	running preemptible RCU?

	Because some other task might have been preempted in the middle

	of an RCU read-side critical section.  If synchronize_rcu()

	can serve as rcu_read_lock_sched(), but is less readable and

	prevents lockdep from detecting locking issues.

	Please not that you *cannot* rely on code known to be built

	Please note that you *cannot* rely on code known to be built

	only in non-preemptible kernels.  Such code can and will break,

	especially in kernels built with CONFIG_PREEMPT_COUNT=y.