Skip to content

Commit cae45e1

Browse files
author
Ingo Molnar
committed
Merge branch 'rcu-next' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/rcu
Pull the latest RCU tree from Paul E. McKenney: - Additional cleanups after RCU flavor consolidation - Grace-period forward-progress cleanups and improvements - Documentation updates - Miscellaneous fixes - spin_is_locked() conversions to lockdep - SPDX changes to RCU source and header files - SRCU updates - Torture-test updates, including nolibc updates and moving nolibc to tools/include Signed-off-by: Ingo Molnar <mingo@kernel.org>
2 parents aa0c38c + e7ffb4e commit cae45e1

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

63 files changed

+1395
-1268
lines changed

‎Documentation/RCU/Design/Expedited-Grace-Periods/ExpSchedFlow.svg

Lines changed: 11 additions & 7 deletions
Loading

‎Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.html

Lines changed: 13 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -72,10 +72,10 @@ <h2><a name="RCU-preempt Expedited Grace Periods">
7272
in quiescent states.
7373
Otherwise, the expedited grace period will use
7474
<tt>smp_call_function_single()</tt> to send the CPU an IPI, which
75-
is handled by <tt>sync_rcu_exp_handler()</tt>.
75+
is handled by <tt>rcu_exp_handler()</tt>.
7676

7777
<p>
78-
However, because this is preemptible RCU, <tt>sync_rcu_exp_handler()</tt>
78+
However, because this is preemptible RCU, <tt>rcu_exp_handler()</tt>
7979
can check to see if the CPU is currently running in an RCU read-side
8080
critical section.
8181
If not, the handler can immediately report a quiescent state.
@@ -145,19 +145,18 @@ <h2><a name="RCU-sched Expedited Grace Periods">
145145
<p><img src="ExpSchedFlow.svg" alt="ExpSchedFlow.svg" width="55%">
146146

147147
<p>
148-
As with RCU-preempt's <tt>synchronize_rcu_expedited()</tt>,
148+
As with RCU-preempt, RCU-sched's
149149
<tt>synchronize_sched_expedited()</tt> ignores offline and
150150
idle CPUs, again because they are in remotely detectable
151151
quiescent states.
152-
However, the <tt>synchronize_rcu_expedited()</tt> handler
153-
is <tt>sync_sched_exp_handler()</tt>, and because the
152+
However, because the
154153
<tt>rcu_read_lock_sched()</tt> and <tt>rcu_read_unlock_sched()</tt>
155154
leave no trace of their invocation, in general it is not possible to tell
156155
whether or not the current CPU is in an RCU read-side critical section.
157-
The best that <tt>sync_sched_exp_handler()</tt> can do is to check
156+
The best that RCU-sched's <tt>rcu_exp_handler()</tt> can do is to check
158157
for idle, on the off-chance that the CPU went idle while the IPI
159158
was in flight.
160-
If the CPU is idle, then <tt>sync_sched_exp_handler()</tt> reports
159+
If the CPU is idle, then <tt>rcu_exp_handler()</tt> reports
161160
the quiescent state.
162161

163162
<p> Otherwise, the handler forces a future context switch by setting the
@@ -298,19 +297,18 @@ <h3><a name="Idle-CPU Checks">Idle-CPU Checks</a></h3>
298297
idle CPUs in the mask passed to <tt>rcu_report_exp_cpu_mult()</tt>.
299298

300299
<p>
301-
For RCU-sched, there is an additional check for idle in the IPI
302-
handler, <tt>sync_sched_exp_handler()</tt>.
300+
For RCU-sched, there is an additional check:
303301
If the IPI has interrupted the idle loop, then
304-
<tt>sync_sched_exp_handler()</tt> invokes <tt>rcu_report_exp_rdp()</tt>
302+
<tt>rcu_exp_handler()</tt> invokes <tt>rcu_report_exp_rdp()</tt>
305303
to report the corresponding quiescent state.
306304

307305
<p>
308306
For RCU-preempt, there is no specific check for idle in the
309-
IPI handler (<tt>sync_rcu_exp_handler()</tt>), but because
307+
IPI handler (<tt>rcu_exp_handler()</tt>), but because
310308
RCU read-side critical sections are not permitted within the
311-
idle loop, if <tt>sync_rcu_exp_handler()</tt> sees that the CPU is within
309+
idle loop, if <tt>rcu_exp_handler()</tt> sees that the CPU is within
312310
RCU read-side critical section, the CPU cannot possibly be idle.
313-
Otherwise, <tt>sync_rcu_exp_handler()</tt> invokes
311+
Otherwise, <tt>rcu_exp_handler()</tt> invokes
314312
<tt>rcu_report_exp_rdp()</tt> to report the corresponding quiescent
315313
state, regardless of whether or not that quiescent state was due to
316314
the CPU being idle.
@@ -625,6 +623,8 @@ <h3><a name="Mid-Boot Operation">Mid-boot operation</a></h3>
625623
<p>
626624
With this refinement, synchronous grace periods can now be used from
627625
task context pretty much any time during the life of the kernel.
626+
That is, aside from some points in the suspend, hibernate, or shutdown
627+
code path.
628628

629629
<h3><a name="Summary">
630630
Summary</a></h3>

‎Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.html

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -485,13 +485,13 @@ <h4><a name="Self-Reported Quiescent States">
485485
noted by <tt>rcu_node_context_switch()</tt> on the left.
486486
On the other hand, if the CPU takes a scheduler-clock interrupt
487487
while executing in usermode, a quiescent state will be noted by
488-
<tt>rcu_check_callbacks()</tt> on the right.
488+
<tt>rcu_sched_clock_irq()</tt> on the right.
489489
Either way, the passage through a quiescent state will be noted
490490
in a per-CPU variable.
491491

492492
<p>The next time an <tt>RCU_SOFTIRQ</tt> handler executes on
493493
this CPU (for example, after the next scheduler-clock
494-
interrupt), <tt>__rcu_process_callbacks()</tt> will invoke
494+
interrupt), <tt>rcu_core()</tt> will invoke
495495
<tt>rcu_check_quiescent_state()</tt>, which will notice the
496496
recorded quiescent state, and invoke
497497
<tt>rcu_report_qs_rdp()</tt>.
@@ -651,7 +651,7 @@ <h4><a name="Callback Invocation">Callback Invocation</a></h4>
651651
These callbacks are identified by <tt>rcu_advance_cbs()</tt>,
652652
which is usually invoked by <tt>__note_gp_changes()</tt>.
653653
As shown in the diagram below, this invocation can be triggered by
654-
the scheduling-clock interrupt (<tt>rcu_check_callbacks()</tt> on
654+
the scheduling-clock interrupt (<tt>rcu_sched_clock_irq()</tt> on
655655
the left) or by idle entry (<tt>rcu_cleanup_after_idle()</tt> on
656656
the right, but only for kernels build with
657657
<tt>CONFIG_RCU_FAST_NO_HZ=y</tt>).

‎Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-invocation.svg

Lines changed: 1 addition & 1 deletion
Loading

‎Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp.svg

Lines changed: 4 additions & 4 deletions
Loading

‎Documentation/RCU/Design/Memory-Ordering/TreeRCU-qs.svg

Lines changed: 3 additions & 3 deletions
Loading

‎Documentation/RCU/Design/Requirements/Requirements.html

Lines changed: 13 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -3099,7 +3099,7 @@ <h3><a name="Sleepable RCU">Sleepable RCU</a></h3>
30993099
sections, then that domain's grace periods will also be blocked forever.
31003100
Of course, one good way to block forever is to deadlock, which can
31013101
happen if any operation in a given domain's SRCU read-side critical
3102-
section can block waiting, either directly or indirectly, for that domain's
3102+
section can wait, either directly or indirectly, for that domain's
31033103
grace period to elapse.
31043104
For example, this results in a self-deadlock:
31053105

@@ -3139,12 +3139,18 @@ <h3><a name="Sleepable RCU">Sleepable RCU</a></h3>
31393139
guarantees a full memory barrier.
31403140

31413141
<p>
3142-
Also unlike other RCU flavors, SRCU's callbacks-wait function
3143-
<tt>srcu_barrier()</tt> may be invoked from CPU-hotplug notifiers,
3144-
though this is not necessarily a good idea.
3145-
The reason that this is possible is that SRCU is insensitive
3146-
to whether or not a CPU is online, which means that <tt>srcu_barrier()</tt>
3147-
need not exclude CPU-hotplug operations.
3142+
Also unlike other RCU flavors, <tt>synchronize_srcu()</tt> may <b>not</b>
3143+
be invoked from CPU-hotplug notifiers, due to the fact that SRCU grace
3144+
periods make use of timers and the possibility of timers being temporarily
3145+
&ldquo;stranded&rdquo; on the outgoing CPU.
3146+
This stranding of timers means that timers posted to the outgoing CPU
3147+
will not fire until late in the CPU-hotplug process.
3148+
The problem is that if a notifier is waiting on an SRCU grace period,
3149+
that grace period is waiting on a timer, and that timer is stranded on the
3150+
outgoing CPU, then the notifier will never be awakened, in other words,
3151+
deadlock has occurred.
3152+
This same situation of course also prohibits <tt>srcu_barrier()</tt>
3153+
from being invoked from CPU-hotplug notifiers.
31483154

31493155
<p>
31503156
SRCU also differs from other RCU flavors in that SRCU's expedited and

‎Documentation/RCU/stallwarn.txt

Lines changed: 8 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -219,17 +219,18 @@ an estimate of the total number of RCU callbacks queued across all CPUs
219219
In kernels with CONFIG_RCU_FAST_NO_HZ, more information is printed
220220
for each CPU:
221221

222-
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 softirq=82/543 last_accelerate: a345/d342 nonlazy_posted: 25 .D
222+
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 softirq=82/543 last_accelerate: a345/d342 Nonlazy posted: ..D
223223

224224
The "last_accelerate:" prints the low-order 16 bits (in hex) of the
225225
jiffies counter when this CPU last invoked rcu_try_advance_all_cbs()
226226
from rcu_needs_cpu() or last invoked rcu_accelerate_cbs() from
227-
rcu_prepare_for_idle(). The "nonlazy_posted:" prints the number
228-
of non-lazy callbacks posted since the last call to rcu_needs_cpu().
229-
Finally, an "L" indicates that there are currently no non-lazy callbacks
230-
("." is printed otherwise, as shown above) and "D" indicates that
231-
dyntick-idle processing is enabled ("." is printed otherwise, for example,
232-
if disabled via the "nohz=" kernel boot parameter).
227+
rcu_prepare_for_idle(). The "Nonlazy posted:" indicates lazy-callback
228+
status, so that an "l" indicates that all callbacks were lazy at the start
229+
of the last idle period and an "L" indicates that there are currently
230+
no non-lazy callbacks (in both cases, "." is printed otherwise, as
231+
shown above) and "D" indicates that dyntick-idle processing is enabled
232+
("." is printed otherwise, for example, if disabled via the "nohz="
233+
kernel boot parameter).
233234

234235
If the grace period ends just as the stall warning starts printing,
235236
there will be a spurious stall-warning message, which will include

0 commit comments

Comments
 (0)