[PATCH 0/3] rcu: Documentation updates for v6.18

[PATCH 0/3] rcu: Documentation updates for v6.18

[Paul E. McKenney]

Hello!

This series contains RCU documentation updates:

1.	Update whatisRCU.rst for recent RCU API additions.

2.	Add RCU guards to checklist.rst.

3.	Requirements.rst: Abide by conventions of kernel documentation,
	courtesy of Akira Yokosawa.

						Thanx, Paul

------------------------------------------------------------------------

 Design/Requirements/Requirements.rst |   52 +++++-------
 checklist.rst                        |   27 ++++--
 whatisRCU.rst                        |  150 +++++++++++++++++++++++++++--------
 3 files changed, 161 insertions(+), 68 deletions(-)

[PATCH 1/3] doc: Update whatisRCU.rst for recent RCU API additions

[Paul E. McKenney]

Bring this file kicking and screaming into the year 2025!

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
---
 Documentation/RCU/whatisRCU.rst | 150 +++++++++++++++++++++++++-------
 1 file changed, 118 insertions(+), 32 deletions(-)

diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst
index be2eb6be16ece8..6c69c20086e147 100644
--- a/Documentation/RCU/whatisRCU.rst
+++ b/Documentation/RCU/whatisRCU.rst
@@ -1021,32 +1021,41 @@ RCU list traversal::
 	list_entry_rcu
 	list_entry_lockless
 	list_first_entry_rcu
+	list_first_or_null_rcu
+	list_tail_rcu
 	list_next_rcu
+	list_next_or_null_rcu
 	list_for_each_entry_rcu
 	list_for_each_entry_continue_rcu
 	list_for_each_entry_from_rcu
-	list_first_or_null_rcu
-	list_next_or_null_rcu
+	list_for_each_entry_lockless
 	hlist_first_rcu
 	hlist_next_rcu
 	hlist_pprev_rcu
 	hlist_for_each_entry_rcu
+	hlist_for_each_entry_rcu_notrace
 	hlist_for_each_entry_rcu_bh
 	hlist_for_each_entry_from_rcu
 	hlist_for_each_entry_continue_rcu
 	hlist_for_each_entry_continue_rcu_bh
 	hlist_nulls_first_rcu
+	hlist_nulls_next_rcu
 	hlist_nulls_for_each_entry_rcu
+	hlist_nulls_for_each_entry_safe
 	hlist_bl_first_rcu
 	hlist_bl_for_each_entry_rcu
 
 RCU pointer/list update::
 
 	rcu_assign_pointer
+	rcu_replace_pointer
+	INIT_LIST_HEAD_RCU
 	list_add_rcu
 	list_add_tail_rcu
 	list_del_rcu
 	list_replace_rcu
+	list_splice_init_rcu
+	list_splice_tail_init_rcu
 	hlist_add_behind_rcu
 	hlist_add_before_rcu
 	hlist_add_head_rcu
@@ -1054,34 +1063,53 @@ RCU pointer/list update::
 	hlist_del_rcu
 	hlist_del_init_rcu
 	hlist_replace_rcu
-	list_splice_init_rcu
-	list_splice_tail_init_rcu
 	hlist_nulls_del_init_rcu
 	hlist_nulls_del_rcu
 	hlist_nulls_add_head_rcu
+	hlist_nulls_add_tail_rcu
+	hlist_nulls_add_fake
+	hlists_swap_heads_rcu
 	hlist_bl_add_head_rcu
-	hlist_bl_del_init_rcu
 	hlist_bl_del_rcu
 	hlist_bl_set_first_rcu
 
 RCU::
 
-	Critical sections	Grace period		Barrier
-
-	rcu_read_lock		synchronize_net		rcu_barrier
-	rcu_read_unlock		synchronize_rcu
-	rcu_dereference		synchronize_rcu_expedited
-	rcu_read_lock_held	call_rcu
-	rcu_dereference_check	kfree_rcu
-	rcu_dereference_protected
+	Critical sections		Grace period		Barrier
+
+	rcu_read_lock			synchronize_net		rcu_barrier
+	rcu_read_unlock			synchronize_rcu
+	guard(rcu)()			synchronize_rcu_expedited
+	scoped_guard(rcu)		synchronize_rcu_mult
+	rcu_dereference			call_rcu
+	rcu_dereference_check		call_rcu_hurry
+	rcu_dereference_protected	kfree_rcu
+	rcu_read_lock_held		kvfree_rcu
+	rcu_read_lock_any_held		kfree_rcu_mightsleep
+	rcu_pointer_handoff		cond_synchronize_rcu
+	unrcu_pointer			cond_synchronize_rcu_full
+					cond_synchronize_rcu_expedited
+					cond_synchronize_rcu_expedited_full
+					get_completed_synchronize_rcu
+					get_completed_synchronize_rcu_full
+					get_state_synchronize_rcu
+					get_state_synchronize_rcu_full
+					poll_state_synchronize_rcu
+					poll_state_synchronize_rcu_full
+					same_state_synchronize_rcu
+					same_state_synchronize_rcu_full
+					start_poll_synchronize_rcu
+					start_poll_synchronize_rcu_full
+					start_poll_synchronize_rcu_expedited
+					start_poll_synchronize_rcu_expedited_full
 
 bh::
 
 	Critical sections	Grace period		Barrier
 
-	rcu_read_lock_bh	call_rcu		rcu_barrier
-	rcu_read_unlock_bh	synchronize_rcu
-	[local_bh_disable]	synchronize_rcu_expedited
+	rcu_read_lock_bh	[Same as RCU]		[Same as RCU]
+	rcu_read_unlock_bh
+	[local_bh_disable]
 	[and friends]
 	rcu_dereference_bh
 	rcu_dereference_bh_check
@@ -1092,9 +1120,9 @@ sched::
 
 	Critical sections	Grace period		Barrier
 
-	rcu_read_lock_sched	call_rcu		rcu_barrier
-	rcu_read_unlock_sched	synchronize_rcu
-	[preempt_disable]	synchronize_rcu_expedited
+	rcu_read_lock_sched	[Same as RCU]		[Same as RCU]
+	rcu_read_unlock_sched
+	[preempt_disable]
 	[and friends]
 	rcu_read_lock_sched_notrace
 	rcu_read_unlock_sched_notrace
@@ -1104,46 +1132,104 @@ sched::
 	rcu_read_lock_sched_held
 
 
+RCU: Initialization/cleanup/ordering::
+
+	RCU_INIT_POINTER
+	RCU_INITIALIZER
+	RCU_POINTER_INITIALIZER
+	init_rcu_head
+	destroy_rcu_head
+	init_rcu_head_on_stack
+	destroy_rcu_head_on_stack
+	SLAB_TYPESAFE_BY_RCU
+
+
+RCU: Quiescents states and control::
+
+	cond_resched_tasks_rcu_qs
+	rcu_all_qs
+	rcu_softirq_qs_periodic
+	rcu_end_inkernel_boot
+	rcu_expedite_gp
+	rcu_gp_is_expedited
+	rcu_unexpedite_gp
+	rcu_cpu_stall_reset
+	rcu_head_after_call_rcu
+	rcu_is_watching
+
+
+RCU-sync primitive:
+
+	rcu_sync_is_idle
+	rcu_sync_init
+	rcu_sync_enter
+	rcu_sync_exit
+	rcu_sync_dtor
+
+
 RCU-Tasks::
 
-	Critical sections	Grace period		Barrier
+	Critical sections	Grace period			Barrier
 
-	N/A			call_rcu_tasks		rcu_barrier_tasks
+	N/A			call_rcu_tasks			rcu_barrier_tasks
 				synchronize_rcu_tasks
 
 
 RCU-Tasks-Rude::
 
-	Critical sections	Grace period		Barrier
+	Critical sections	Grace period			Barrier
 
-	N/A						N/A
-				synchronize_rcu_tasks_rude
+	N/A			synchronize_rcu_tasks_rude	rcu_barrier_tasks_rude
+				call_rcu_tasks_rude
 
 
 RCU-Tasks-Trace::
 
-	Critical sections	Grace period		Barrier
+	Critical sections	Grace period			Barrier
 
-	rcu_read_lock_trace	call_rcu_tasks_trace	rcu_barrier_tasks_trace
+	rcu_read_lock_trace	call_rcu_tasks_trace		rcu_barrier_tasks_trace
 	rcu_read_unlock_trace	synchronize_rcu_tasks_trace
+	guard(rcu_tasks_trace)()
+	scoped_guard(rcu_tasks_trace)
 
 
-SRCU::
+SRCU list traversal::
+	list_for_each_entry_srcu
+	hlist_for_each_entry_srcu
 
-	Critical sections	Grace period		Barrier
 
-	srcu_read_lock		call_srcu		srcu_barrier
-	srcu_read_unlock	synchronize_srcu
-	srcu_dereference	synchronize_srcu_expedited
+SRCU::
+
+	Critical sections		Grace period		Barrier
+
+	srcu_read_lock			call_srcu		srcu_barrier
+	srcu_read_unlock		synchronize_srcu
+	srcu_read_lock_fast		synchronize_srcu_expedited
+	srcu_read_unlock_fast		get_state_synchronize_srcu
+	srcu_read_lock_nmisafe		start_poll_synchronize_srcu
+	srcu_read_unlock_nmisafe	start_poll_synchronize_srcu_expedited
+	srcu_read_lock_notrace		poll_state_synchronize_srcu
+	srcu_read_unlock_notrace
+	srcu_down_read
+	srcu_up_read
+	srcu_down_read_fast
+	srcu_up_read_fast
+	guard(srcu)()
+	scoped_guard(srcu)
+	srcu_read_lock_held
+	srcu_dereference
 	srcu_dereference_check
+	srcu_dereference_notrace
 	srcu_read_lock_held
 
-SRCU: Initialization/cleanup::
+
+SRCU: Initialization/cleanup/ordering::
 
 	DEFINE_SRCU
 	DEFINE_STATIC_SRCU
 	init_srcu_struct
 	cleanup_srcu_struct
+	smp_mb__after_srcu_read_unlock
 
 All: lockdep-checked RCU utility APIs::
 
-- 
2.40.1

[PATCH 2/3] doc: Add RCU guards to checklist.rst

[Paul E. McKenney]

Also note that RCU guards can be easier to use.

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
---
 Documentation/RCU/checklist.rst | 27 +++++++++++++++++++--------
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst
index 7de3e308f330f6..c9bfb2b218e525 100644
--- a/Documentation/RCU/checklist.rst
+++ b/Documentation/RCU/checklist.rst
@@ -69,7 +69,13 @@ over a rather long period of time, but improvements are always welcome!
 	Explicit disabling of preemption (preempt_disable(), for example)
 	can serve as rcu_read_lock_sched(), but is less readable and
 	prevents lockdep from detecting locking issues.  Acquiring a
-	spinlock also enters an RCU read-side critical section.
+	raw spinlock also enters an RCU read-side critical section.
+
+	The guard(rcu)() and scoped_guard(rcu) primitives designate
+	the remainder of the current scope or the next statement,
+	respectively, as the RCU read-side critical section.  Use of
+	these guards can be less error-prone than rcu_read_lock(),
+	rcu_read_unlock(), and friends.
 
 	Please note that you *cannot* rely on code known to be built
 	only in non-preemptible kernels.  Such code can and will break,
@@ -405,9 +411,11 @@ over a rather long period of time, but improvements are always welcome!
 13.	Unlike most flavors of RCU, it *is* permissible to block in an
 	SRCU read-side critical section (demarked by srcu_read_lock()
 	and srcu_read_unlock()), hence the "SRCU": "sleepable RCU".
-	Please note that if you don't need to sleep in read-side critical
-	sections, you should be using RCU rather than SRCU, because RCU
-	is almost always faster and easier to use than is SRCU.
+	As with RCU, guard(srcu)() and scoped_guard(srcu) forms are
+	available, and often provide greater ease of use.  Please note
+	that if you don't need to sleep in read-side critical sections,
+	you should be using RCU rather than SRCU, because RCU is almost
+	always faster and easier to use than is SRCU.
 
 	Also unlike other forms of RCU, explicit initialization and
 	cleanup is required either at build time via DEFINE_SRCU()
@@ -443,10 +451,13 @@ over a rather long period of time, but improvements are always welcome!
 	real-time workloads than is synchronize_rcu_expedited().
 
 	It is also permissible to sleep in RCU Tasks Trace read-side
-	critical section, which are delimited by rcu_read_lock_trace() and
-	rcu_read_unlock_trace().  However, this is a specialized flavor
-	of RCU, and you should not use it without first checking with
-	its current users.  In most cases, you should instead use SRCU.
+	critical section, which are delimited by rcu_read_lock_trace()
+	and rcu_read_unlock_trace().  However, this is a specialized
+	flavor of RCU, and you should not use it without first checking
+	with its current users.  In most cases, you should instead
+	use SRCU.  As with RCU and SRCU, guard(rcu_tasks_trace)() and
+	scoped_guard(rcu_tasks_trace) are available, and often provide
+	greater ease of use.
 
 	Note that rcu_assign_pointer() relates to SRCU just as it does to
 	other forms of RCU, but instead of rcu_dereference() you should
-- 
2.40.1

[PATCH 3/3] rcu: docs: Requirements.rst: Abide by conventions of kernel documentation

[Paul E. McKenney]

From: Akira Yokosawa <akiyks@gmail.com>

Here is a list of conventions applied here:

- Don't mark up function names, to be taken care of by the automarkup
  extension.  Just say func().
- Instead of ".. code-block:: none", just say "::".
- Mark inline literals by a pair of ``xxxx``.  Don't use rust doc's
  dialect of `yyyy`.
- Instead of emphasizing headings by **strong emphasis**, use sub-level
  title adornments, in this case "^^^^^^^^^^" and make them proper
  sub-sections under "Hotplug CPU".

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
Cc: Joel Fernandes <joelagnelf@nvidia.com>
Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.upadhyay@kernel.org>
---
 .../RCU/Design/Requirements/Requirements.rst  | 52 +++++++++----------
 1 file changed, 24 insertions(+), 28 deletions(-)

diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
index b0395540296b00..f24b3c0b9b0dc6 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.rst
+++ b/Documentation/RCU/Design/Requirements/Requirements.rst
@@ -1973,9 +1973,7 @@ code, and the FQS loop, all of which refer to or modify this bookkeeping.
 Note that grace period initialization (rcu_gp_init()) must carefully sequence
 CPU hotplug scanning with grace period state changes. For example, the
 following race could occur in rcu_gp_init() if rcu_seq_start() were to happen
-after the CPU hotplug scanning.
-
-.. code-block:: none
+after the CPU hotplug scanning::
 
    CPU0 (rcu_gp_init)                   CPU1                          CPU2
    ---------------------                ----                          ----
@@ -2008,22 +2006,22 @@ after the CPU hotplug scanning.
                                                                       kfree(r1);
                                         r2 = *r0; // USE-AFTER-FREE!
 
-By incrementing gp_seq first, CPU1's RCU read-side critical section
+By incrementing ``gp_seq`` first, CPU1's RCU read-side critical section
 is guaranteed to not be missed by CPU2.
 
-**Concurrent Quiescent State Reporting for Offline CPUs**
+Concurrent Quiescent State Reporting for Offline CPUs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 RCU must ensure that CPUs going offline report quiescent states to avoid
 blocking grace periods. This requires careful synchronization to handle
 race conditions
 
-**Race condition causing Offline CPU to hang GP**
-
-A race between CPU offlining and new GP initialization (gp_init) may occur
-because `rcu_report_qs_rnp()` in `rcutree_report_cpu_dead()` must temporarily
-release the `rcu_node` lock to wake the RCU grace-period kthread:
+Race condition causing Offline CPU to hang GP
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-.. code-block:: none
+A race between CPU offlining and new GP initialization (gp_init()) may occur
+because rcu_report_qs_rnp() in rcutree_report_cpu_dead() must temporarily
+release the ``rcu_node`` lock to wake the RCU grace-period kthread::
 
    CPU1 (going offline)                 CPU0 (GP kthread)
    --------------------                 -----------------
@@ -2044,15 +2042,14 @@ release the `rcu_node` lock to wake the RCU grace-period kthread:
        // Reacquire lock (but too late)
      rnp->qsmaskinitnext &= ~mask       // Finally clears bit
 
-Without `ofl_lock`, the new grace period includes the offline CPU and waits
+Without ``ofl_lock``, the new grace period includes the offline CPU and waits
 forever for its quiescent state causing a GP hang.
 
-**A solution with ofl_lock**
+A solution with ofl_lock
+^^^^^^^^^^^^^^^^^^^^^^^^
 
-The `ofl_lock` (offline lock) prevents `rcu_gp_init()` from running during
-the vulnerable window when `rcu_report_qs_rnp()` has released `rnp->lock`:
-
-.. code-block:: none
+The ``ofl_lock`` (offline lock) prevents rcu_gp_init() from running during
+the vulnerable window when rcu_report_qs_rnp() has released ``rnp->lock``::
 
    CPU0 (rcu_gp_init)                   CPU1 (rcutree_report_cpu_dead)
    ------------------                   ------------------------------
@@ -2065,21 +2062,20 @@ the vulnerable window when `rcu_report_qs_rnp()` has released `rnp->lock`:
        arch_spin_unlock(&ofl_lock) ---> // Now CPU1 can proceed
    }                                    // But snapshot already taken
 
-**Another race causing GP hangs in rcu_gpu_init(): Reporting QS for Now-offline CPUs**
+Another race causing GP hangs in rcu_gpu_init(): Reporting QS for Now-offline CPUs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 After the first loop takes an atomic snapshot of online CPUs, as shown above,
-the second loop in `rcu_gp_init()` detects CPUs that went offline between
-releasing `ofl_lock` and acquiring the per-node `rnp->lock`. This detection is
-crucial because:
+the second loop in rcu_gp_init() detects CPUs that went offline between
+releasing ``ofl_lock`` and acquiring the per-node ``rnp->lock``.
+This detection is crucial because:
 
 1. The CPU might have gone offline after the snapshot but before the second loop
 2. The offline CPU cannot report its own QS if it's already dead
 3. Without this detection, the grace period would wait forever for CPUs that
    are now offline.
 
-The second loop performs this detection safely:
-
-.. code-block:: none
+The second loop performs this detection safely::
 
    rcu_for_each_node_breadth_first(rnp) {
        raw_spin_lock_irqsave_rcu_node(rnp, flags);
@@ -2093,10 +2089,10 @@ The second loop performs this detection safely:
    }
 
 This approach ensures atomicity: quiescent state reporting for offline CPUs
-happens either in `rcu_gp_init()` (second loop) or in `rcutree_report_cpu_dead()`,
-never both and never neither. The `rnp->lock` held throughout the sequence
-prevents races - `rcutree_report_cpu_dead()` also acquires this lock when
-clearing `qsmaskinitnext`, ensuring mutual exclusion.
+happens either in rcu_gp_init() (second loop) or in rcutree_report_cpu_dead(),
+never both and never neither. The ``rnp->lock`` held throughout the sequence
+prevents races - rcutree_report_cpu_dead() also acquires this lock when
+clearing ``qsmaskinitnext``, ensuring mutual exclusion.
 
 Scheduler and RCU
 ~~~~~~~~~~~~~~~~~
-- 
2.40.1

Re: [PATCH 3/3] rcu: docs: Requirements.rst: Abide by conventions of kernel documentation

[Akira Yokosawa]

On Fri, 15 Aug 2025 17:00:07 -0700, Paul E. McKenney wrote:
> From: Akira Yokosawa <akiyks@gmail.com>
> 
> Here is a list of conventions applied here:
> 
> - Don't mark up function names, to be taken care of by the automarkup
>   extension.  Just say func().
> - Instead of ".. code-block:: none", just say "::".
> - Mark inline literals by a pair of ``xxxx``.  Don't use rust doc's
>   dialect of `yyyy`.
> - Instead of emphasizing headings by **strong emphasis**, use sub-level
>   title adornments, in this case "^^^^^^^^^^" and make them proper
>   sub-sections under "Hotplug CPU".
> 
> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> Cc: Joel Fernandes <joelagnelf@nvidia.com>
> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.upadhyay@kernel.org>

Missing S-o-b of Paul?

Joel, I'd rather like to have your ack here.  Could you?

        Thanks, Akira

> ---
>  .../RCU/Design/Requirements/Requirements.rst  | 52 +++++++++----------
>  1 file changed, 24 insertions(+), 28 deletions(-)
> 
[...]

Re: [PATCH 3/3] rcu: docs: Requirements.rst: Abide by conventions of kernel documentation

[Paul E. McKenney]

On Sat, Aug 16, 2025 at 10:30:24AM +0900, Akira Yokosawa wrote:
> On Fri, 15 Aug 2025 17:00:07 -0700, Paul E. McKenney wrote:
> > From: Akira Yokosawa <akiyks@gmail.com>
> > 
> > Here is a list of conventions applied here:
> > 
> > - Don't mark up function names, to be taken care of by the automarkup
> >   extension.  Just say func().
> > - Instead of ".. code-block:: none", just say "::".
> > - Mark inline literals by a pair of ``xxxx``.  Don't use rust doc's
> >   dialect of `yyyy`.
> > - Instead of emphasizing headings by **strong emphasis**, use sub-level
> >   title adornments, in this case "^^^^^^^^^^" and make them proper
> >   sub-sections under "Hotplug CPU".
> > 
> > Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> > Cc: Joel Fernandes <joelagnelf@nvidia.com>
> > Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.upadhyay@kernel.org>
> 
> Missing S-o-b of Paul?

My fault when pulling in changes from Neeraj, will fix, thank you!

> Joel, I'd rather like to have your ack here.  Could you?

I would be happy to add that as well.  ;-)

							Thanx, Paul

>         Thanks, Akira
> 
> > ---
> >  .../RCU/Design/Requirements/Requirements.rst  | 52 +++++++++----------
> >  1 file changed, 24 insertions(+), 28 deletions(-)
> > 
> [...]
> 

Re: [PATCH 1/3] doc: Update whatisRCU.rst for recent RCU API additions

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

On Fri, Aug 15, 2025 at 05:00:05PM -0700, Paul E. McKenney wrote:
> +RCU: Initialization/cleanup/ordering::
> +
> +	RCU_INIT_POINTER
> +	RCU_INITIALIZER
> +	RCU_POINTER_INITIALIZER
> +	init_rcu_head
> +	destroy_rcu_head
> +	init_rcu_head_on_stack
> +	destroy_rcu_head_on_stack
> +	SLAB_TYPESAFE_BY_RCU
> +
> +
> +RCU: Quiescents states and control::
> +
> +	cond_resched_tasks_rcu_qs
> +	rcu_all_qs
> +	rcu_softirq_qs_periodic
> +	rcu_end_inkernel_boot
> +	rcu_expedite_gp
> +	rcu_gp_is_expedited
> +	rcu_unexpedite_gp
> +	rcu_cpu_stall_reset
> +	rcu_head_after_call_rcu
> +	rcu_is_watching
> +
> +
> +RCU-sync primitive:
> +
> +	rcu_sync_is_idle
> +	rcu_sync_init
> +	rcu_sync_enter
> +	rcu_sync_exit
> +	rcu_sync_dtor

Looks like inconsistent (normal paragraph instead of literal code block like
the rest).

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 1/3] doc: Update whatisRCU.rst for recent RCU API additions

[Paul E. McKenney]

On Sat, Aug 16, 2025 at 10:54:04AM +0700, Bagas Sanjaya wrote:
> On Fri, Aug 15, 2025 at 05:00:05PM -0700, Paul E. McKenney wrote:
> > +RCU: Initialization/cleanup/ordering::
> > +
> > +	RCU_INIT_POINTER
> > +	RCU_INITIALIZER
> > +	RCU_POINTER_INITIALIZER
> > +	init_rcu_head
> > +	destroy_rcu_head
> > +	init_rcu_head_on_stack
> > +	destroy_rcu_head_on_stack
> > +	SLAB_TYPESAFE_BY_RCU
> > +
> > +
> > +RCU: Quiescents states and control::
> > +
> > +	cond_resched_tasks_rcu_qs
> > +	rcu_all_qs
> > +	rcu_softirq_qs_periodic
> > +	rcu_end_inkernel_boot
> > +	rcu_expedite_gp
> > +	rcu_gp_is_expedited
> > +	rcu_unexpedite_gp
> > +	rcu_cpu_stall_reset
> > +	rcu_head_after_call_rcu
> > +	rcu_is_watching
> > +
> > +
> > +RCU-sync primitive:
> > +
> > +	rcu_sync_is_idle
> > +	rcu_sync_init
> > +	rcu_sync_enter
> > +	rcu_sync_exit
> > +	rcu_sync_dtor
> 
> Looks like inconsistent (normal paragraph instead of literal code block like
> the rest).

As in the "RCU-sync primitive:" needs another colon (":") at the end of
that line?  If so, agreed, will fix on next rebase, and thank you!

							Thanx, Paul

Re: [PATCH 1/3] doc: Update whatisRCU.rst for recent RCU API additions

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

On Fri, Aug 15, 2025 at 09:54:57PM -0700, Paul E. McKenney wrote:
> On Sat, Aug 16, 2025 at 10:54:04AM +0700, Bagas Sanjaya wrote:
> > On Fri, Aug 15, 2025 at 05:00:05PM -0700, Paul E. McKenney wrote:
> > > +RCU: Initialization/cleanup/ordering::
> > > +
> > > +	RCU_INIT_POINTER
> > > +	RCU_INITIALIZER
> > > +	RCU_POINTER_INITIALIZER
> > > +	init_rcu_head
> > > +	destroy_rcu_head
> > > +	init_rcu_head_on_stack
> > > +	destroy_rcu_head_on_stack
> > > +	SLAB_TYPESAFE_BY_RCU
> > > +
> > > +
> > > +RCU: Quiescents states and control::
> > > +
> > > +	cond_resched_tasks_rcu_qs
> > > +	rcu_all_qs
> > > +	rcu_softirq_qs_periodic
> > > +	rcu_end_inkernel_boot
> > > +	rcu_expedite_gp
> > > +	rcu_gp_is_expedited
> > > +	rcu_unexpedite_gp
> > > +	rcu_cpu_stall_reset
> > > +	rcu_head_after_call_rcu
> > > +	rcu_is_watching
> > > +
> > > +
> > > +RCU-sync primitive:
> > > +
> > > +	rcu_sync_is_idle
> > > +	rcu_sync_init
> > > +	rcu_sync_enter
> > > +	rcu_sync_exit
> > > +	rcu_sync_dtor
> > 
> > Looks like inconsistent (normal paragraph instead of literal code block like
> > the rest).
> 
> As in the "RCU-sync primitive:" needs another colon (":") at the end of
> that line?  If so, agreed, will fix on next rebase, and thank you!
> 

Yup, that's what I mean.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 1/3] doc: Update whatisRCU.rst for recent RCU API additions

[Paul E. McKenney]

On Sat, Aug 16, 2025 at 12:38:05PM +0700, Bagas Sanjaya wrote:
> On Fri, Aug 15, 2025 at 09:54:57PM -0700, Paul E. McKenney wrote:
> > On Sat, Aug 16, 2025 at 10:54:04AM +0700, Bagas Sanjaya wrote:
> > > On Fri, Aug 15, 2025 at 05:00:05PM -0700, Paul E. McKenney wrote:
> > > > +RCU: Initialization/cleanup/ordering::
> > > > +
> > > > +	RCU_INIT_POINTER
> > > > +	RCU_INITIALIZER
> > > > +	RCU_POINTER_INITIALIZER
> > > > +	init_rcu_head
> > > > +	destroy_rcu_head
> > > > +	init_rcu_head_on_stack
> > > > +	destroy_rcu_head_on_stack
> > > > +	SLAB_TYPESAFE_BY_RCU
> > > > +
> > > > +
> > > > +RCU: Quiescents states and control::
> > > > +
> > > > +	cond_resched_tasks_rcu_qs
> > > > +	rcu_all_qs
> > > > +	rcu_softirq_qs_periodic
> > > > +	rcu_end_inkernel_boot
> > > > +	rcu_expedite_gp
> > > > +	rcu_gp_is_expedited
> > > > +	rcu_unexpedite_gp
> > > > +	rcu_cpu_stall_reset
> > > > +	rcu_head_after_call_rcu
> > > > +	rcu_is_watching
> > > > +
> > > > +
> > > > +RCU-sync primitive:
> > > > +
> > > > +	rcu_sync_is_idle
> > > > +	rcu_sync_init
> > > > +	rcu_sync_enter
> > > > +	rcu_sync_exit
> > > > +	rcu_sync_dtor
> > > 
> > > Looks like inconsistent (normal paragraph instead of literal code block like
> > > the rest).
> > 
> > As in the "RCU-sync primitive:" needs another colon (":") at the end of
> > that line?  If so, agreed, will fix on next rebase, and thank you!
> > 
> 
> Yup, that's what I mean.

Got it, and again, thank you!

							Thanx, Paul