| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20230130052458.GQ2948950@paulmck-ThinkPad-P17-Gen-1>
Date: Sun, 29 Jan 2023 21:24:58 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Randy Dunlap <rdunlap@...radead.org>
Cc: linux-kernel@...r.kernel.org, Jonathan Corbet <corbet@....net>,
linux-doc@...r.kernel.org,
Frederic Weisbecker <frederic@...nel.org>,
Neeraj Upadhyay <quic_neeraju@...cinc.com>,
Josh Triplett <josh@...htriplett.org>, rcu@...r.kernel.org
Subject: Re: [PATCH 5/9] Documentation: RCU: correct spelling
On Sun, Jan 29, 2023 at 03:10:49PM -0800, Randy Dunlap wrote:
> Correct spelling problems for Documentation/RCU/ as reported
> by codespell.
>
> Note: in RTFP.txt, there are other misspellings that are left as is
> since they were used that way in email Subject: lines or in LWN.net
> articles. [preemptable, Preemptable, synchonisation]
>
> Signed-off-by: Randy Dunlap <rdunlap@...radead.org>
> Cc: Jonathan Corbet <corbet@....net>
> Cc: linux-doc@...r.kernel.org
> Cc: "Paul E. McKenney" <paulmck@...nel.org>
> Cc: Frederic Weisbecker <frederic@...nel.org>
> Cc: Neeraj Upadhyay <quic_neeraju@...cinc.com>
> Cc: Josh Triplett <josh@...htriplett.org>
> Cc: rcu@...r.kernel.org
Queued despite affinitied being a perfectly cromulent word. ;-)
Thank you!
Thanx, Paul
> ---
> .../Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst | 6 +++---
> .../Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst | 2 +-
> .../RTFP.txt | 10 +++++-----
> .../UP.rst | 4 ++--
> .../lockdep.rst | 2 +-
> .../torture.rst | 4 ++--
> 6 files changed, 14 insertions(+), 14 deletions(-)
>
> diff -- a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst
> --- a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst
> +++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst
> @@ -277,7 +277,7 @@ the following access functions:
>
> 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.
> @@ -405,7 +405,7 @@ Use of Workqueues
> 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
> @@ -465,7 +465,7 @@ corresponding disadvantage that workqueu
> 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
> diff -- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
> --- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
> +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
> @@ -168,7 +168,7 @@ an ``atomic_add_return()`` of zero) to d
> +-----------------------------------------------------------------------+
>
> 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
> diff -- a/Documentation/RCU/lockdep.rst b/Documentation/RCU/lockdep.rst
> --- a/Documentation/RCU/lockdep.rst
> +++ b/Documentation/RCU/lockdep.rst
> @@ -65,7 +65,7 @@ checking of rcu_dereference() primitives
> rcu_access_pointer(p):
> Return the value of the pointer and omit all barriers,
> but retain the compiler constraints that prevent duplicating
> - or coalescsing. This is useful when testing the
> + or coalescing. This is useful when testing the
> value of the pointer itself, for example, against NULL.
>
> The rcu_dereference_check() check expression can be any boolean
> diff -- a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt
> --- a/Documentation/RCU/RTFP.txt
> +++ b/Documentation/RCU/RTFP.txt
> @@ -201,7 +201,7 @@ work looked at debugging uses of RCU [Se
> 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,
> @@ -1245,7 +1245,7 @@ Oregon Health and Sciences University"
> [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.
> }
> }
>
> @@ -1888,7 +1888,7 @@ Revised:
> \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.)
> }
> }
> @@ -2275,7 +2275,7 @@ lot of {Linux} into your technology!!!"
> \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.
> }
> }
>
> @@ -2639,7 +2639,7 @@ lot of {Linux} into your technology!!!"
> 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.
> diff -- a/Documentation/RCU/torture.rst b/Documentation/RCU/torture.rst
> --- a/Documentation/RCU/torture.rst
> +++ b/Documentation/RCU/torture.rst
> @@ -216,7 +216,7 @@ Kernel boot arguments can also be suppli
> rcutorture's module parameters. For example, to test a change to RCU's
> CPU stall-warning code, use "--bootargs 'rcutorture.stall_cpu=30'".
> This will of course result in the scripting reporting a failure, namely
> -the resuling RCU CPU stall warning. As noted above, reducing memory may
> +the resulting RCU CPU stall warning. As noted above, reducing memory may
> require disabling rcutorture's callback-flooding tests::
>
> kvm.sh --cpus 448 --configs '56*TREE04' --memory 128M \
> @@ -370,5 +370,5 @@ You can also re-run a previous remote ru
> tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28-remote \
> --duration 24h
>
> -In this case, most of the kvm-again.sh parmeters may be supplied following
> +In this case, most of the kvm-again.sh parameters may be supplied following
> the pathname of the old run-results directory.
> diff -- a/Documentation/RCU/UP.rst b/Documentation/RCU/UP.rst
> --- a/Documentation/RCU/UP.rst
> +++ b/Documentation/RCU/UP.rst
> @@ -107,7 +107,7 @@ UP systems, including PREEMPT SMP builds
>
> Quick Quiz #3:
> Why can't synchronize_rcu() return immediately on UP systems running
> - preemptable RCU?
> + preemptible RCU?
>
> .. _answer_quick_quiz_up:
>
> @@ -143,7 +143,7 @@ Answer to Quick Quiz #2:
>
> 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()
Powered by blists - more mailing lists