Skip to content

Commit 067610e

Browse files
committed
Merge tag 'rcu.release.v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux
Pull RCU updates from Neeraj Upadhyay: "Context tracking: - rename context tracking state related symbols and remove references to "dynticks" in various context tracking state variables and related helpers - force context_tracking_enabled_this_cpu() to be inlined to avoid leaving a noinstr section CSD lock: - enhance CSD-lock diagnostic reports - add an API to provide an indication of ongoing CSD-lock stall nocb: - update and simplify RCU nocb code to handle (de-)offloading of callbacks only for offline CPUs - fix RT throttling hrtimer being armed from offline CPU rcutorture: - remove redundant rcu_torture_ops get_gp_completed fields - add SRCU ->same_gp_state and ->get_comp_state functions - add generic test for NUM_ACTIVE_*RCU_POLL* for testing RCU and SRCU polled grace periods - add CFcommon.arch for arch-specific Kconfig options - print number of update types in rcu_torture_write_types() - add rcutree.nohz_full_patience_delay testing to the TREE07 scenario - add a stall_cpu_repeat module parameter to test repeated CPU stalls - add argument to limit number of CPUs a guest OS can use in torture.sh rcustall: - abbreviate RCU CPU stall warnings during CSD-lock stalls - Allow dump_cpu_task() to be called without disabling preemption - defer printing stall-warning backtrace when holding rcu_node lock srcu: - make SRCU gp seq wrap-around faster - add KCSAN checks for concurrent updates to ->srcu_n_exp_nodelay and ->reschedule_count which are used in heuristics governing auto-expediting of normal SRCU grace periods and grace-period-state-machine delays - mark idle SRCU-barrier callbacks to help identify stuck SRCU-barrier callback rcu tasks: - remove RCU Tasks Rude asynchronous APIs as they are no longer used - stop testing RCU Tasks Rude asynchronous APIs - fix access to non-existent percpu regions - check processor-ID assumptions during chosen CPU calculation for callback enqueuing - update description of rtp->tasks_gp_seq grace-period sequence number - add rcu_barrier_cb_is_done() to identify whether a given rcu_barrier callback is stuck - mark idle Tasks-RCU-barrier callbacks - add *torture_stats_print() functions to print detailed diagnostics for Tasks-RCU variants - capture start time of rcu_barrier_tasks*() operation to help distinguish a hung barrier operation from a long series of barrier operations refscale: - add a TINY scenario to support tests of Tiny RCU and Tiny SRCU - optimize process_durations() operation rcuscale: - dump stacks of stalled rcu_scale_writer() instances and grace-period statistics when rcu_scale_writer() stalls - mark idle RCU-barrier callbacks to identify stuck RCU-barrier callbacks - print detailed grace-period and barrier diagnostics on rcu_scale_writer() hangs for Tasks-RCU variants - warn if async module parameter is specified for RCU implementations that do not have async primitives such as RCU Tasks Rude - make all writer tasks report upon hang - tolerate repeated GFP_KERNEL failure in rcu_scale_writer() - use special allocator for rcu_scale_writer() - NULL out top-level pointers to heap memory to avoid double-free bugs on modprobe failures - maintain per-task instead of per-CPU callbacks count to avoid any issues with migration of either tasks or callbacks - constify struct ref_scale_ops Fixes: - use system_unbound_wq for kfree_rcu work to avoid disturbing isolated CPUs Misc: - warn on unexpected rcu_state.srs_done_tail state - better define "atomic" for list_replace_rcu() and hlist_replace_rcu() routines - annotate struct kvfree_rcu_bulk_data with __counted_by()" * tag 'rcu.release.v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux: (90 commits) rcu: Defer printing stall-warning backtrace when holding rcu_node lock rcu/nocb: Remove superfluous memory barrier after bypass enqueue rcu/nocb: Conditionally wake up rcuo if not already waiting on GP rcu/nocb: Fix RT throttling hrtimer armed from offline CPU rcu/nocb: Simplify (de-)offloading state machine context_tracking: Tag context_tracking_enabled_this_cpu() __always_inline context_tracking, rcu: Rename rcu_dyntick trace event into rcu_watching rcu: Update stray documentation references to rcu_dynticks_eqs_{enter, exit}() rcu: Rename rcu_momentary_dyntick_idle() into rcu_momentary_eqs() rcu: Rename rcu_implicit_dynticks_qs() into rcu_watching_snap_recheck() rcu: Rename dyntick_save_progress_counter() into rcu_watching_snap_save() rcu: Rename struct rcu_data .exp_dynticks_snap into .exp_watching_snap rcu: Rename struct rcu_data .dynticks_snap into .watching_snap rcu: Rename rcu_dynticks_zero_in_eqs() into rcu_watching_zero_in_eqs() rcu: Rename rcu_dynticks_in_eqs_since() into rcu_watching_snap_stopped_since() rcu: Rename rcu_dynticks_in_eqs() into rcu_watching_snap_in_eqs() rcu: Rename rcu_dynticks_eqs_online() into rcu_watching_online() context_tracking, rcu: Rename rcu_dynticks_curr_cpu_in_eqs() into rcu_is_watching_curr_cpu() context_tracking, rcu: Rename rcu_dynticks_task*() into rcu_task*() refscale: Constify struct ref_scale_ops ...
2 parents 85a77db + 355debb commit 067610e

Some content is hidden

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

57 files changed

+1088
-786
lines changed

Documentation/RCU/Design/Data-Structures/Data-Structures.rst

Lines changed: 14 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -921,10 +921,10 @@ This portion of the ``rcu_data`` structure is declared as follows:
921921

922922
::
923923

924-
1 int dynticks_snap;
924+
1 int watching_snap;
925925
2 unsigned long dynticks_fqs;
926926

927-
The ``->dynticks_snap`` field is used to take a snapshot of the
927+
The ``->watching_snap`` field is used to take a snapshot of the
928928
corresponding CPU's dyntick-idle state when forcing quiescent states,
929929
and is therefore accessed from other CPUs. Finally, the
930930
``->dynticks_fqs`` field is used to count the number of times this CPU
@@ -935,8 +935,8 @@ This portion of the rcu_data structure is declared as follows:
935935

936936
::
937937

938-
1 long dynticks_nesting;
939-
2 long dynticks_nmi_nesting;
938+
1 long nesting;
939+
2 long nmi_nesting;
940940
3 atomic_t dynticks;
941941
4 bool rcu_need_heavy_qs;
942942
5 bool rcu_urgent_qs;
@@ -945,27 +945,27 @@ These fields in the rcu_data structure maintain the per-CPU dyntick-idle
945945
state for the corresponding CPU. The fields may be accessed only from
946946
the corresponding CPU (and from tracing) unless otherwise stated.
947947

948-
The ``->dynticks_nesting`` field counts the nesting depth of process
948+
The ``->nesting`` field counts the nesting depth of process
949949
execution, so that in normal circumstances this counter has value zero
950950
or one. NMIs, irqs, and tracers are counted by the
951-
``->dynticks_nmi_nesting`` field. Because NMIs cannot be masked, changes
951+
``->nmi_nesting`` field. Because NMIs cannot be masked, changes
952952
to this variable have to be undertaken carefully using an algorithm
953953
provided by Andy Lutomirski. The initial transition from idle adds one,
954954
and nested transitions add two, so that a nesting level of five is
955-
represented by a ``->dynticks_nmi_nesting`` value of nine. This counter
955+
represented by a ``->nmi_nesting`` value of nine. This counter
956956
can therefore be thought of as counting the number of reasons why this
957957
CPU cannot be permitted to enter dyntick-idle mode, aside from
958958
process-level transitions.
959959

960960
However, it turns out that when running in non-idle kernel context, the
961961
Linux kernel is fully capable of entering interrupt handlers that never
962962
exit and perhaps also vice versa. Therefore, whenever the
963-
``->dynticks_nesting`` field is incremented up from zero, the
964-
``->dynticks_nmi_nesting`` field is set to a large positive number, and
965-
whenever the ``->dynticks_nesting`` field is decremented down to zero,
966-
the ``->dynticks_nmi_nesting`` field is set to zero. Assuming that
963+
``->nesting`` field is incremented up from zero, the
964+
``->nmi_nesting`` field is set to a large positive number, and
965+
whenever the ``->nesting`` field is decremented down to zero,
966+
the ``->nmi_nesting`` field is set to zero. Assuming that
967967
the number of misnested interrupts is not sufficient to overflow the
968-
counter, this approach corrects the ``->dynticks_nmi_nesting`` field
968+
counter, this approach corrects the ``->nmi_nesting`` field
969969
every time the corresponding CPU enters the idle loop from process
970970
context.
971971

@@ -992,8 +992,8 @@ code.
992992
+-----------------------------------------------------------------------+
993993
| **Quick Quiz**: |
994994
+-----------------------------------------------------------------------+
995-
| Why not simply combine the ``->dynticks_nesting`` and |
996-
| ``->dynticks_nmi_nesting`` counters into a single counter that just |
995+
| Why not simply combine the ``->nesting`` and |
996+
| ``->nmi_nesting`` counters into a single counter that just |
997997
| counts the number of reasons that the corresponding CPU is non-idle? |
998998
+-----------------------------------------------------------------------+
999999
| **Answer**: |

Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -147,10 +147,10 @@ RCU read-side critical sections preceding and following the current
147147
idle sojourn.
148148
This case is handled by calls to the strongly ordered
149149
``atomic_add_return()`` read-modify-write atomic operation that
150-
is invoked within ``rcu_dynticks_eqs_enter()`` at idle-entry
151-
time and within ``rcu_dynticks_eqs_exit()`` at idle-exit time.
152-
The grace-period kthread invokes first ``ct_dynticks_cpu_acquire()``
153-
(preceded by a full memory barrier) and ``rcu_dynticks_in_eqs_since()``
150+
is invoked within ``ct_kernel_exit_state()`` at idle-entry
151+
time and within ``ct_kernel_enter_state()`` at idle-exit time.
152+
The grace-period kthread invokes first ``ct_rcu_watching_cpu_acquire()``
153+
(preceded by a full memory barrier) and ``rcu_watching_snap_stopped_since()``
154154
(both of which rely on acquire semantics) to detect idle CPUs.
155155

156156
+-----------------------------------------------------------------------+

Documentation/RCU/Design/Memory-Ordering/TreeRCU-dyntick.svg

Lines changed: 4 additions & 4 deletions
Loading

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

Lines changed: 4 additions & 4 deletions
Loading

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

Lines changed: 4 additions & 4 deletions
Loading

Documentation/RCU/Design/Memory-Ordering/TreeRCU-hotplug.svg

Lines changed: 2 additions & 2 deletions
Loading

Documentation/RCU/Design/Requirements/Requirements.rst

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2649,8 +2649,7 @@ those that are idle from RCU's perspective) and then Tasks Rude RCU can
26492649
be removed from the kernel.
26502650

26512651
The tasks-rude-RCU API is also reader-marking-free and thus quite compact,
2652-
consisting of call_rcu_tasks_rude(), synchronize_rcu_tasks_rude(),
2653-
and rcu_barrier_tasks_rude().
2652+
consisting solely of synchronize_rcu_tasks_rude().
26542653

26552654
Tasks Trace RCU
26562655
~~~~~~~~~~~~~~~

Documentation/RCU/checklist.rst

Lines changed: 28 additions & 33 deletions
Original file line numberDiff line numberDiff line change
@@ -194,14 +194,13 @@ over a rather long period of time, but improvements are always welcome!
194194
when publicizing a pointer to a structure that can
195195
be traversed by an RCU read-side critical section.
196196

197-
5. If any of call_rcu(), call_srcu(), call_rcu_tasks(),
198-
call_rcu_tasks_rude(), or call_rcu_tasks_trace() is used,
199-
the callback function may be invoked from softirq context,
200-
and in any case with bottom halves disabled. In particular,
201-
this callback function cannot block. If you need the callback
202-
to block, run that code in a workqueue handler scheduled from
203-
the callback. The queue_rcu_work() function does this for you
204-
in the case of call_rcu().
197+
5. If any of call_rcu(), call_srcu(), call_rcu_tasks(), or
198+
call_rcu_tasks_trace() is used, the callback function may be
199+
invoked from softirq context, and in any case with bottom halves
200+
disabled. In particular, this callback function cannot block.
201+
If you need the callback to block, run that code in a workqueue
202+
handler scheduled from the callback. The queue_rcu_work()
203+
function does this for you in the case of call_rcu().
205204

206205
6. Since synchronize_rcu() can block, it cannot be called
207206
from any sort of irq context. The same rule applies
@@ -254,10 +253,10 @@ over a rather long period of time, but improvements are always welcome!
254253
corresponding readers must use rcu_read_lock_trace()
255254
and rcu_read_unlock_trace().
256255

257-
c. If an updater uses call_rcu_tasks_rude() or
258-
synchronize_rcu_tasks_rude(), then the corresponding
259-
readers must use anything that disables preemption,
260-
for example, preempt_disable() and preempt_enable().
256+
c. If an updater uses synchronize_rcu_tasks_rude(),
257+
then the corresponding readers must use anything that
258+
disables preemption, for example, preempt_disable()
259+
and preempt_enable().
261260

262261
Mixing things up will result in confusion and broken kernels, and
263262
has even resulted in an exploitable security issue. Therefore,
@@ -326,11 +325,9 @@ over a rather long period of time, but improvements are always welcome!
326325
d. Periodically invoke rcu_barrier(), permitting a limited
327326
number of updates per grace period.
328327

329-
The same cautions apply to call_srcu(), call_rcu_tasks(),
330-
call_rcu_tasks_rude(), and call_rcu_tasks_trace(). This is
331-
why there is an srcu_barrier(), rcu_barrier_tasks(),
332-
rcu_barrier_tasks_rude(), and rcu_barrier_tasks_rude(),
333-
respectively.
328+
The same cautions apply to call_srcu(), call_rcu_tasks(), and
329+
call_rcu_tasks_trace(). This is why there is an srcu_barrier(),
330+
rcu_barrier_tasks(), and rcu_barrier_tasks_trace(), respectively.
334331

335332
Note that although these primitives do take action to avoid
336333
memory exhaustion when any given CPU has too many callbacks,
@@ -383,17 +380,17 @@ over a rather long period of time, but improvements are always welcome!
383380
must use whatever locking or other synchronization is required
384381
to safely access and/or modify that data structure.
385382

386-
Do not assume that RCU callbacks will be executed on
387-
the same CPU that executed the corresponding call_rcu(),
388-
call_srcu(), call_rcu_tasks(), call_rcu_tasks_rude(), or
389-
call_rcu_tasks_trace(). For example, if a given CPU goes offline
390-
while having an RCU callback pending, then that RCU callback
391-
will execute on some surviving CPU. (If this was not the case,
392-
a self-spawning RCU callback would prevent the victim CPU from
393-
ever going offline.) Furthermore, CPUs designated by rcu_nocbs=
394-
might well *always* have their RCU callbacks executed on some
395-
other CPUs, in fact, for some real-time workloads, this is the
396-
whole point of using the rcu_nocbs= kernel boot parameter.
383+
Do not assume that RCU callbacks will be executed on the same
384+
CPU that executed the corresponding call_rcu(), call_srcu(),
385+
call_rcu_tasks(), or call_rcu_tasks_trace(). For example, if
386+
a given CPU goes offline while having an RCU callback pending,
387+
then that RCU callback will execute on some surviving CPU.
388+
(If this was not the case, a self-spawning RCU callback would
389+
prevent the victim CPU from ever going offline.) Furthermore,
390+
CPUs designated by rcu_nocbs= might well *always* have their
391+
RCU callbacks executed on some other CPUs, in fact, for some
392+
real-time workloads, this is the whole point of using the
393+
rcu_nocbs= kernel boot parameter.
397394

398395
In addition, do not assume that callbacks queued in a given order
399396
will be invoked in that order, even if they all are queued on the
@@ -507,9 +504,9 @@ over a rather long period of time, but improvements are always welcome!
507504
These debugging aids can help you find problems that are
508505
otherwise extremely difficult to spot.
509506

510-
17. If you pass a callback function defined within a module to one of
511-
call_rcu(), call_srcu(), call_rcu_tasks(), call_rcu_tasks_rude(),
512-
or call_rcu_tasks_trace(), then it is necessary to wait for all
507+
17. If you pass a callback function defined within a module
508+
to one of call_rcu(), call_srcu(), call_rcu_tasks(), or
509+
call_rcu_tasks_trace(), then it is necessary to wait for all
513510
pending callbacks to be invoked before unloading that module.
514511
Note that it is absolutely *not* sufficient to wait for a grace
515512
period! For example, synchronize_rcu() implementation is *not*
@@ -522,7 +519,6 @@ over a rather long period of time, but improvements are always welcome!
522519
- call_rcu() -> rcu_barrier()
523520
- call_srcu() -> srcu_barrier()
524521
- call_rcu_tasks() -> rcu_barrier_tasks()
525-
- call_rcu_tasks_rude() -> rcu_barrier_tasks_rude()
526522
- call_rcu_tasks_trace() -> rcu_barrier_tasks_trace()
527523

528524
However, these barrier functions are absolutely *not* guaranteed
@@ -539,7 +535,6 @@ over a rather long period of time, but improvements are always welcome!
539535
- Either synchronize_srcu() or synchronize_srcu_expedited(),
540536
together with and srcu_barrier()
541537
- synchronize_rcu_tasks() and rcu_barrier_tasks()
542-
- synchronize_tasks_rude() and rcu_barrier_tasks_rude()
543538
- synchronize_tasks_trace() and rcu_barrier_tasks_trace()
544539

545540
If necessary, you can use something like workqueues to execute

Documentation/RCU/whatisRCU.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1103,7 +1103,7 @@ RCU-Tasks-Rude::
11031103

11041104
Critical sections Grace period Barrier
11051105

1106-
N/A call_rcu_tasks_rude rcu_barrier_tasks_rude
1106+
N/A N/A
11071107
synchronize_rcu_tasks_rude
11081108

11091109

Documentation/admin-guide/kernel-parameters.txt

Lines changed: 11 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -4969,6 +4969,10 @@
49694969
Set maximum number of finished RCU callbacks to
49704970
process in one batch.
49714971

4972+
rcutree.csd_lock_suppress_rcu_stall= [KNL]
4973+
Do only a one-line RCU CPU stall warning when
4974+
there is an ongoing too-long CSD-lock wait.
4975+
49724976
rcutree.do_rcu_barrier= [KNL]
49734977
Request a call to rcu_barrier(). This is
49744978
throttled so that userspace tests can safely
@@ -5416,7 +5420,13 @@
54165420
Time to wait (s) after boot before inducing stall.
54175421

54185422
rcutorture.stall_cpu_irqsoff= [KNL]
5419-
Disable interrupts while stalling if set.
5423+
Disable interrupts while stalling if set, but only
5424+
on the first stall in the set.
5425+
5426+
rcutorture.stall_cpu_repeat= [KNL]
5427+
Number of times to repeat the stall sequence,
5428+
so that rcutorture.stall_cpu_repeat=3 will result
5429+
in four stall sequences.
54205430

54215431
rcutorture.stall_gp_kthread= [KNL]
54225432
Duration (s) of forced sleep within RCU
@@ -5604,14 +5614,6 @@
56045614
of zero will disable batching. Batching is
56055615
always disabled for synchronize_rcu_tasks().
56065616

5607-
rcupdate.rcu_tasks_rude_lazy_ms= [KNL]
5608-
Set timeout in milliseconds RCU Tasks
5609-
Rude asynchronous callback batching for
5610-
call_rcu_tasks_rude(). A negative value
5611-
will take the default. A value of zero will
5612-
disable batching. Batching is always disabled
5613-
for synchronize_rcu_tasks_rude().
5614-
56155617
rcupdate.rcu_tasks_trace_lazy_ms= [KNL]
56165618
Set timeout in milliseconds RCU Tasks
56175619
Trace asynchronous callback batching for

0 commit comments

Comments
 (0)