On Mon, Feb 16, 2026 at 12:43:09PM +0800, Kunwu Chan wrote:
> Signed-off-by: Kunwu Chan <[email protected]>
Good eyes, applied and pushed, and thank you!!!
Thanx, Paul
> ---
> defer/rcu.tex | 2 +-
> defer/rcuapi.tex | 4 ++--
> defer/rcufundamental.tex | 2 +-
> defer/rcuintro.tex | 2 +-
> defer/rcurelated.tex | 2 +-
> defer/rcuusage.tex | 10 +++++-----
> defer/updates.tex | 2 +-
> defer/whichtochoose.tex | 2 +-
> 8 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/defer/rcu.tex b/defer/rcu.tex
> index c54da410..13078687 100644
> --- a/defer/rcu.tex
> +++ b/defer/rcu.tex
> @@ -66,7 +66,7 @@ applied to virtually any data structure''.
> On the other hand, making good use of RCU often requires that you think
> differently about concurrency in general and about your use case in
> particular.
> -Much of the remainder of this section therofore provides a guide to
> +Much of the remainder of this section therefore provides a guide to
> mapping use cases onto RCU.
>
> \QuickQuiz{
> diff --git a/defer/rcuapi.tex b/defer/rcuapi.tex
> index 54c94233..9fa11626 100644
> --- a/defer/rcuapi.tex
> +++ b/defer/rcuapi.tex
> @@ -135,7 +135,7 @@ and by
> which shows the publish-subscribe portions of the
> API~\cite{PaulEMcKenney2024RCUAPI}.\footnote{
> This citation covers v6.10 and later.
> - Documetation for earlier versions of the Linux-kernel RCU API may
> + Documentation for earlier versions of the Linux-kernel RCU API may
> be found
> elsewhere~\cite{PaulEMcKenney2008WhatIsRCUAPI,PaulEMcKenney2014RCUAPI,PaulEMcKenney2019RCUAPI}.}
>
> \begin{sidewaystable*}[tbp]
> @@ -597,7 +597,7 @@ However, there are situations where this ease of use gets
> in the way,
> for example, when a cache of RCU-protected objects might be subject
> to reuse during the grace period that otherwise would have allowed them
> to be freed.
> -Although this can be handed through careful use of flags that interact
> +Although this can be handled through careful use of flags that interact
> with the RCU callback queued by \co{call_rcu()}, this can be inconvenient
> and can waste CPU times due to the overhead of the doomed \co{call_rcu()}
> invocations.
> diff --git a/defer/rcufundamental.tex b/defer/rcufundamental.tex
> index 0efdf406..c3bcc4f0 100644
> --- a/defer/rcufundamental.tex
> +++ b/defer/rcufundamental.tex
> @@ -484,7 +484,7 @@ In contrast, in
> \cref{fig:defer:Multiple RCU Data-Structure Versions}
> the reader sees a version that never actually existed!
>
> -One way to resolve this strange situation is via weaker semanitics.
> +One way to resolve this strange situation is via weaker semantics.
> A reader traversal must encounter any data item that was present
> during the full traversal (B, C, and~D), and might or might not
> encounter data items that were present for only part of the
> diff --git a/defer/rcuintro.tex b/defer/rcuintro.tex
> index d3a55a47..48de32e2 100644
> --- a/defer/rcuintro.tex
> +++ b/defer/rcuintro.tex
> @@ -145,7 +145,7 @@ the state, as indicated by the ``2~Versions'' in the
> figure.
> to model.
>
> Real-world algorithms therefore absolutely must tolerate
> - inconsistancies between external reality and the in-computer
> + inconsistencies between external reality and the in-computer
> data reflecting that reality.
> Many of those algorithms are also able to tolerate some degree
> of inconsistency within the in-computer data.
> diff --git a/defer/rcurelated.tex b/defer/rcurelated.tex
> index 8846825f..cf4b7b49 100644
> --- a/defer/rcurelated.tex
> +++ b/defer/rcurelated.tex
> @@ -391,7 +391,7 @@ sleepable RCU (SRCU)~\cite{PaulEMcKenney2006c}.
> Finally, \ppl{Michalis}{Kokologiannakis} and \ppl{Konstantinos}{Sagonas}
> (National Technical University of
>
> Athens)~\cite{MichalisKokologiannakis2017NidhuggRCU,MichalisKokologiannakis2019RCUstatelessModelCheck}
> -used the Nighugg tool~\cite{CarlLeonardsson2014Nidhugg}
> +used the Nidhugg tool~\cite{CarlLeonardsson2014Nidhugg}
> to produce a mechanical proof of correctness of a somewhat larger
> portion of Linux-kernel Tree RCU\@.
>
> diff --git a/defer/rcuusage.tex b/defer/rcuusage.tex
> index 6225c672..63e12a40 100644
> --- a/defer/rcuusage.tex
> +++ b/defer/rcuusage.tex
> @@ -226,7 +226,7 @@ that of the ideal synchronization-free workload.
> \end{figure*}
>
> Although Pre-BSD routing is an excellent RCU use case, it is worthwhile
> -looking at the relationships betweeen the wider spectrum of use cases
> +looking at the relationships between the wider spectrum of use cases
> shown in
> \cref{fig:defer:Relationships Between RCU Use Cases}.
> This task is taken up by the following sections.
> @@ -520,7 +520,7 @@ run concurrently with \co{do_maint()} to complete, and
> finally
> function's load from \co{be_careful} and any memory loads
> executed by the \co{cco_quickly()} function.
> Because there is no ordering, without that second call to
> - \co{syncrhonize_rcu()}, memory ordering could cause loads
> + \co{synchronize_rcu()}, memory ordering could cause loads
> in \co{cco_quickly()} to overlap with stores by \co{do_maint()}.
>
> Another alternative would be to compensate for the removal of
> @@ -852,7 +852,7 @@ and \clnref{ret_0:b} indicates failure to delete the
> specified key.
> \QuickQuizE{
> The RCU-based algorithm shown in
> \cref{lst:defer:Existence Guarantees Enable Per-Element Locking}
> - locks very similar to that in
> + looks very similar to that in
> \cref{lst:locking:Per-Element Locking With Lock-Based Existence
> Guarantees},
> so why should the RCU-based approach be any better?
> }\QuickQuizAnswerE{
> @@ -1057,7 +1057,7 @@ which was generated on a 448-CPU 2.10\,GHz Intel x86
> system.
>
> Nor was this a theoretical problem:
> A failure actually manifested in 2019.
> - \ppl{Herbert}{Xu} tracked down this failure down and
> + \ppl{Herbert}{Xu} tracked down this failure and
> \ppl{Linus}{Torvalds}
> therefore queued a commit to upgrade \co{rcu_read_lock()} and
> \co{rcu_read_unlock()} to unconditionally include a call to
> @@ -1356,7 +1356,7 @@ analysis~\cite[Figures 3 and
> 5]{VishakhaRamani2023LockBasedLocklessFresh}.
> at the time that it arrives, and extremely stale in the case
> of astronomical data.
> The finite speed of light also places a sharp limit on the
> - consistency of data arriving from different sources of via
> + consistency of data arriving from different sources or via
> different paths.
>
> You might as well face the fact that the laws of physics
> diff --git a/defer/updates.tex b/defer/updates.tex
> index 92e1fe93..7536e172 100644
> --- a/defer/updates.tex
> +++ b/defer/updates.tex
> @@ -21,7 +21,7 @@ scalability for writers, namely the counting algorithms
> surveyed in
> These algorithms featured partially partitioned data structures so
> that updates can operate locally, while the more-expensive reads
> must sum across the entire data structure.
> -Silas Boyd-Wickhizer has generalized this notion to produce
> +Silas Boyd-Wickizer has generalized this notion to produce
> OpLog, which he has applied to
> Linux-kernel pathname lookup, VM reverse mappings, and the \co{stat()} system
> call~\cite{SilasBoydWickizerPhD}.
> diff --git a/defer/whichtochoose.tex b/defer/whichtochoose.tex
> index dfa19426..775da269 100644
> --- a/defer/whichtochoose.tex
> +++ b/defer/whichtochoose.tex
> @@ -397,7 +397,7 @@ instructions.
> This limits lock contention and prevents both preemption and
> interrupts from delaying execution while those locks are held,
> in turn providing excellent forward
> -
> progrees~\cite{BjoernBrandenburgPhD,DanielBristot2019RTtrace,Hillier86,DipankarSarma2004OLSscalability}.
> +
> progress~\cite{BjoernBrandenburgPhD,DanielBristot2019RTtrace,Hillier86,DipankarSarma2004OLSscalability}.
>
> In short, formalisms such as wait-free synchronization have their
> place, but the really important thing is to figure out what your
> --
> 2.25.1
>
