* [PATCH 0/9] Documentation: correct lots of spelling errors (series 2)
@ 2023-01-29 23:10 Randy Dunlap
2023-01-29 23:10 ` [PATCH 5/9] Documentation: RCU: correct spelling Randy Dunlap
` (3 more replies)
0 siblings, 4 replies; 11+ messages in thread
From: Randy Dunlap @ 2023-01-29 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Jonathan Corbet, linux-doc, Tejun Heo, Zefan Li,
Johannes Weiner, cgroups, Alasdair Kergon, Mike Snitzer, dm-devel,
Mauro Carvalho Chehab, linux-media, linux-mm, Dan Williams,
Vishal Verma, Dave Jiang, nvdimm, Vinod Koul, dmaengine, Song Liu,
linux-raid, Greg Kroah-Hartman, linux-usb, Jean Delvare,
Guenter Roeck, linux-hwmon, Jiri Pirko, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev,
Paul E. McKenney, Frederic Weisbecker, Neeraj Upadhyay,
Josh Triplett, rcu, James E.J. Bottomley, Martin K. Petersen,
linux-scsi, sparclinux
Maintainers of specific kernel subsystems are only Cc-ed on their
respective patches, not the entire series. [if all goes well]
These patches are based on linux-next-20230127.
[PATCH 1/9] Documentation: admin-guide: correct spelling
[PATCH 2/9] Documentation: driver-api: correct spelling
[PATCH 3/9] Documentation: hwmon: correct spelling
[PATCH 4/9] Documentation: networking: correct spelling
[PATCH 5/9] Documentation: RCU: correct spelling
[PATCH 6/9] Documentation: scsi/ChangeLog*: correct spelling
[PATCH 7/9] Documentation: scsi: correct spelling
[PATCH 8/9] Documentation: sparc: correct spelling
[PATCH 9/9] Documentation: userspace-api: correct spelling
Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst | 6 -
Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst | 2
Documentation/RCU/RTFP.txt | 10 +-
Documentation/RCU/UP.rst | 4
Documentation/RCU/lockdep.rst | 2
Documentation/RCU/torture.rst | 4
Documentation/admin-guide/bcache.rst | 2
Documentation/admin-guide/cgroup-v1/blkio-controller.rst | 2
Documentation/admin-guide/cgroup-v2.rst | 10 +-
Documentation/admin-guide/cifs/usage.rst | 4
Documentation/admin-guide/device-mapper/cache-policies.rst | 2
Documentation/admin-guide/device-mapper/dm-ebs.rst | 2
Documentation/admin-guide/device-mapper/dm-zoned.rst | 2
Documentation/admin-guide/device-mapper/unstriped.rst | 10 +-
Documentation/admin-guide/dynamic-debug-howto.rst | 2
Documentation/admin-guide/gpio/gpio-sim.rst | 2
Documentation/admin-guide/hw-vuln/mds.rst | 4
Documentation/admin-guide/kernel-parameters.txt | 8 -
Documentation/admin-guide/laptops/thinkpad-acpi.rst | 2
Documentation/admin-guide/md.rst | 2
Documentation/admin-guide/media/bttv.rst | 2
Documentation/admin-guide/media/building.rst | 2
Documentation/admin-guide/media/si476x.rst | 2
Documentation/admin-guide/media/vivid.rst | 2
Documentation/admin-guide/mm/hugetlbpage.rst | 2
Documentation/admin-guide/mm/numa_memory_policy.rst | 4
Documentation/admin-guide/perf/hns3-pmu.rst | 2
Documentation/admin-guide/pm/amd-pstate.rst | 2
Documentation/admin-guide/spkguide.txt | 4
Documentation/admin-guide/sysctl/vm.rst | 4
Documentation/admin-guide/sysrq.rst | 2
Documentation/driver-api/dma-buf.rst | 2
Documentation/driver-api/dmaengine/client.rst | 2
Documentation/driver-api/dmaengine/dmatest.rst | 2
Documentation/driver-api/hsi.rst | 4
Documentation/driver-api/io-mapping.rst | 4
Documentation/driver-api/md/md-cluster.rst | 2
Documentation/driver-api/md/raid5-cache.rst | 2
Documentation/driver-api/media/drivers/vidtv.rst | 2
Documentation/driver-api/media/dtv-demux.rst | 2
Documentation/driver-api/media/v4l2-subdev.rst | 4
Documentation/driver-api/mei/nfc.rst | 2
Documentation/driver-api/nfc/nfc-hci.rst | 2
Documentation/driver-api/nvdimm/nvdimm.rst | 2
Documentation/driver-api/nvdimm/security.rst | 2
Documentation/driver-api/pin-control.rst | 2
Documentation/driver-api/pldmfw/index.rst | 2
Documentation/driver-api/serial/driver.rst | 2
Documentation/driver-api/surface_aggregator/ssh.rst | 2
Documentation/driver-api/thermal/intel_powerclamp.rst | 2
Documentation/driver-api/usb/dwc3.rst | 2
Documentation/driver-api/usb/usb3-debug-port.rst | 2
Documentation/hwmon/aht10.rst | 2
Documentation/hwmon/aspeed-pwm-tacho.rst | 2
Documentation/hwmon/corsair-psu.rst | 2
Documentation/hwmon/gsc-hwmon.rst | 6 -
Documentation/hwmon/hwmon-kernel-api.rst | 4
Documentation/hwmon/ltc2978.rst | 2
Documentation/hwmon/max6697.rst | 2
Documentation/hwmon/menf21bmc.rst | 2
Documentation/hwmon/pmbus-core.rst | 2
Documentation/hwmon/sht4x.rst | 2
Documentation/hwmon/smm665.rst | 2
Documentation/hwmon/stpddc60.rst | 2
Documentation/hwmon/vexpress.rst | 2
Documentation/hwmon/via686a.rst | 2
Documentation/networking/af_xdp.rst | 4
Documentation/networking/arcnet-hardware.rst | 2
Documentation/networking/can.rst | 2
Documentation/networking/can_ucan_protocol.rst | 2
Documentation/networking/cdc_mbim.rst | 2
Documentation/networking/device_drivers/atm/iphase.rst | 2
Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst | 4
Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg | 4
Documentation/networking/device_drivers/ethernet/3com/vortex.rst | 2
Documentation/networking/device_drivers/ethernet/aquantia/atlantic.rst | 6 -
Documentation/networking/device_drivers/ethernet/freescale/dpaa2/mac-phy-support.rst | 2
Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst | 2
Documentation/networking/device_drivers/ethernet/pensando/ionic.rst | 2
Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst | 2
Documentation/networking/device_drivers/ethernet/ti/cpsw_switchdev.rst | 2
Documentation/networking/device_drivers/wwan/iosm.rst | 2
Documentation/networking/devlink/ice.rst | 4
Documentation/networking/devlink/netdevsim.rst | 2
Documentation/networking/devlink/prestera.rst | 2
Documentation/networking/dsa/configuration.rst | 2
Documentation/networking/ethtool-netlink.rst | 6 -
Documentation/networking/gtp.rst | 2
Documentation/networking/ieee802154.rst | 2
Documentation/networking/ip-sysctl.rst | 6 -
Documentation/networking/ipvlan.rst | 2
Documentation/networking/j1939.rst | 2
Documentation/networking/net_failover.rst | 2
Documentation/networking/netconsole.rst | 2
Documentation/networking/page_pool.rst | 6 -
Documentation/networking/phonet.rst | 2
Documentation/networking/phy.rst | 2
Documentation/networking/regulatory.rst | 4
Documentation/networking/rxrpc.rst | 2
Documentation/networking/snmp_counter.rst | 4
Documentation/networking/sysfs-tagging.rst | 2
Documentation/scsi/ChangeLog.lpfc | 36 ++++----
Documentation/scsi/ChangeLog.megaraid | 8 -
Documentation/scsi/ChangeLog.megaraid_sas | 4
Documentation/scsi/ChangeLog.ncr53c8xx | 16 +--
Documentation/scsi/ChangeLog.sym53c8xx | 14 +--
Documentation/scsi/ChangeLog.sym53c8xx_2 | 10 +-
Documentation/scsi/ncr53c8xx.rst | 4
Documentation/scsi/sym53c8xx_2.rst | 2
Documentation/scsi/tcm_qla2xxx.rst | 2
Documentation/scsi/ufs.rst | 2
Documentation/sparc/adi.rst | 4
Documentation/sparc/oradax/dax-hv-api.txt | 44 +++++-----
Documentation/userspace-api/iommufd.rst | 2
Documentation/userspace-api/media/drivers/st-vgxy61.rst | 2
Documentation/userspace-api/media/rc/lirc-set-wideband-receiver.rst | 2
Documentation/userspace-api/media/rc/rc-protos.rst | 2
Documentation/userspace-api/media/rc/rc-tables.rst | 2
Documentation/userspace-api/media/v4l/dev-sliced-vbi.rst | 2
Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst | 2
Documentation/userspace-api/media/v4l/ext-ctrls-jpeg.rst | 2
Documentation/userspace-api/media/v4l/hist-v4l2.rst | 4
Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst | 2
Documentation/userspace-api/media/v4l/vidioc-cropcap.rst | 2
Documentation/userspace-api/seccomp_filter.rst | 2
Documentation/userspace-api/sysfs-platform_profile.rst | 2
126 files changed, 232 insertions(+), 232 deletions(-)
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Cc: Tejun Heo <tj@kernel.org>
Cc: Zefan Li <lizefan.x@bytedance.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: cgroups@vger.kernel.org
Cc: Alasdair Kergon <agk@redhat.com>
Cc: Mike Snitzer <snitzer@kernel.org>
Cc: dm-devel@redhat.com
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: linux-media@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: nvdimm@lists.linux.dev
Cc: Vinod Koul <vkoul@kernel.org>
Cc: dmaengine@vger.kernel.org
Cc: Song Liu <song@kernel.org>
Cc: linux-raid@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org
Cc: Jiri Pirko <jiri@nvidia.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org
Cc: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Neeraj Upadhyay <quic_neeraju@quicinc.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: rcu@vger.kernel.org
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org
Cc: sparclinux@vger.kernel.org
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 5/9] Documentation: RCU: correct spelling
2023-01-29 23:10 [PATCH 0/9] Documentation: correct lots of spelling errors (series 2) Randy Dunlap
@ 2023-01-29 23:10 ` Randy Dunlap
2023-01-30 5:24 ` Paul E. McKenney
2023-01-31 12:10 ` [PATCH 0/9] Documentation: correct lots of spelling errors (series 2) patchwork-bot+netdevbpf
` (2 subsequent siblings)
3 siblings, 1 reply; 11+ messages in thread
From: Randy Dunlap @ 2023-01-29 23:10 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Jonathan Corbet, linux-doc, Paul E. McKenney,
Frederic Weisbecker, Neeraj Upadhyay, Josh Triplett, rcu
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@infradead.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Cc: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Neeraj Upadhyay <quic_neeraju@quicinc.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: rcu@vger.kernel.org
---
.../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()
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 5/9] Documentation: RCU: correct spelling
2023-01-29 23:10 ` [PATCH 5/9] Documentation: RCU: correct spelling Randy Dunlap
@ 2023-01-30 5:24 ` Paul E. McKenney
0 siblings, 0 replies; 11+ messages in thread
From: Paul E. McKenney @ 2023-01-30 5:24 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-kernel, Jonathan Corbet, linux-doc, Frederic Weisbecker,
Neeraj Upadhyay, Josh Triplett, rcu
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@infradead.org>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-doc@vger.kernel.org
> Cc: "Paul E. McKenney" <paulmck@kernel.org>
> Cc: Frederic Weisbecker <frederic@kernel.org>
> Cc: Neeraj Upadhyay <quic_neeraju@quicinc.com>
> Cc: Josh Triplett <josh@joshtriplett.org>
> Cc: rcu@vger.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()
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/9] Documentation: correct lots of spelling errors (series 2)
2023-01-29 23:10 [PATCH 0/9] Documentation: correct lots of spelling errors (series 2) Randy Dunlap
2023-01-29 23:10 ` [PATCH 5/9] Documentation: RCU: correct spelling Randy Dunlap
@ 2023-01-31 12:10 ` patchwork-bot+netdevbpf
2023-01-31 12:17 ` Paolo Abeni
2023-02-02 18:09 ` Jonathan Corbet
2023-02-14 16:57 ` (subset) " Martin K. Petersen
3 siblings, 1 reply; 11+ messages in thread
From: patchwork-bot+netdevbpf @ 2023-01-31 12:10 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-kernel, corbet, linux-doc, tj, lizefan.x, hannes, cgroups,
agk, snitzer, dm-devel, mchehab, linux-media, linux-mm,
dan.j.williams, vishal.l.verma, dave.jiang, nvdimm, vkoul,
dmaengine, song, linux-raid, gregkh, linux-usb, jdelvare, linux,
linux-hwmon, jiri, davem, edumazet, kuba, pabeni, netdev, paulmck,
frederic, quic_neeraju, josh, rcu, jejb, martin.petersen,
linux-scsi, sparclinux
Hello:
This patch was applied to netdev/net-next.git (master)
by Paolo Abeni <pabeni@redhat.com>:
On Sun, 29 Jan 2023 15:10:44 -0800 you wrote:
> Maintainers of specific kernel subsystems are only Cc-ed on their
> respective patches, not the entire series. [if all goes well]
>
> These patches are based on linux-next-20230127.
>
>
> [PATCH 1/9] Documentation: admin-guide: correct spelling
> [PATCH 2/9] Documentation: driver-api: correct spelling
> [PATCH 3/9] Documentation: hwmon: correct spelling
> [PATCH 4/9] Documentation: networking: correct spelling
> [PATCH 5/9] Documentation: RCU: correct spelling
> [PATCH 6/9] Documentation: scsi/ChangeLog*: correct spelling
> [PATCH 7/9] Documentation: scsi: correct spelling
> [PATCH 8/9] Documentation: sparc: correct spelling
> [PATCH 9/9] Documentation: userspace-api: correct spelling
>
> [...]
Here is the summary with links:
- [4/9] Documentation: networking: correct spelling
https://git.kernel.org/netdev/net-next/c/a266ef69b890
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/9] Documentation: correct lots of spelling errors (series 2)
2023-01-31 12:10 ` [PATCH 0/9] Documentation: correct lots of spelling errors (series 2) patchwork-bot+netdevbpf
@ 2023-01-31 12:17 ` Paolo Abeni
0 siblings, 0 replies; 11+ messages in thread
From: Paolo Abeni @ 2023-01-31 12:17 UTC (permalink / raw)
To: patchwork-bot+netdevbpf, Randy Dunlap
Cc: linux-kernel, corbet, linux-doc, tj, lizefan.x, hannes, cgroups,
agk, snitzer, dm-devel, mchehab, linux-media, linux-mm,
dan.j.williams, vishal.l.verma, dave.jiang, nvdimm, vkoul,
dmaengine, song, linux-raid, gregkh, linux-usb, jdelvare, linux,
linux-hwmon, jiri, davem, edumazet, kuba, netdev, paulmck,
frederic, quic_neeraju, josh, rcu, jejb, martin.petersen,
linux-scsi, sparclinux
On Tue, 2023-01-31 at 12:10 +0000, patchwork-bot+netdevbpf@kernel.org
wrote:
> Hello:
>
> This patch was applied to netdev/net-next.git (master)
> by Paolo Abeni <pabeni@redhat.com>:
>
> On Sun, 29 Jan 2023 15:10:44 -0800 you wrote:
> > Maintainers of specific kernel subsystems are only Cc-ed on their
> > respective patches, not the entire series. [if all goes well]
> >
> > These patches are based on linux-next-20230127.
> >
> >
> > [PATCH 1/9] Documentation: admin-guide: correct spelling
> > [PATCH 2/9] Documentation: driver-api: correct spelling
> > [PATCH 3/9] Documentation: hwmon: correct spelling
> > [PATCH 4/9] Documentation: networking: correct spelling
> > [PATCH 5/9] Documentation: RCU: correct spelling
> > [PATCH 6/9] Documentation: scsi/ChangeLog*: correct spelling
> > [PATCH 7/9] Documentation: scsi: correct spelling
> > [PATCH 8/9] Documentation: sparc: correct spelling
> > [PATCH 9/9] Documentation: userspace-api: correct spelling
> >
> > [...]
>
> Here is the summary with links:
> - [4/9] Documentation: networking: correct spelling
> https://git.kernel.org/netdev/net-next/c/a266ef69b890
>
> You are awesome, thank you!
That is just a bot glitch. I actually applied only patch 4/9 to the
net-next tree. I hope this is not too much scarying/confusing.
Thanks,
Paolo
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/9] Documentation: correct lots of spelling errors (series 2)
2023-01-29 23:10 [PATCH 0/9] Documentation: correct lots of spelling errors (series 2) Randy Dunlap
2023-01-29 23:10 ` [PATCH 5/9] Documentation: RCU: correct spelling Randy Dunlap
2023-01-31 12:10 ` [PATCH 0/9] Documentation: correct lots of spelling errors (series 2) patchwork-bot+netdevbpf
@ 2023-02-02 18:09 ` Jonathan Corbet
2023-02-02 18:33 ` Randy Dunlap
2023-02-14 16:57 ` (subset) " Martin K. Petersen
3 siblings, 1 reply; 11+ messages in thread
From: Jonathan Corbet @ 2023-02-02 18:09 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel
Cc: Randy Dunlap, linux-doc, Tejun Heo, Zefan Li, Johannes Weiner,
cgroups, Alasdair Kergon, Mike Snitzer, dm-devel,
Mauro Carvalho Chehab, linux-media, linux-mm, Dan Williams,
Vishal Verma, Dave Jiang, nvdimm, Vinod Koul, dmaengine, Song Liu,
linux-raid, Greg Kroah-Hartman, linux-usb, Jean Delvare,
Guenter Roeck, linux-hwmon, Jiri Pirko, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev,
Paul E. McKenney, Frederic Weisbecker, Neeraj Upadhyay,
Josh Triplett, rcu, James E.J. Bottomley, Martin K. Petersen,
linux-scsi, sparclinux
Randy Dunlap <rdunlap@infradead.org> writes:
> Maintainers of specific kernel subsystems are only Cc-ed on their
> respective patches, not the entire series. [if all goes well]
>
> These patches are based on linux-next-20230127.
So I've applied a bunch of these
> [PATCH 1/9] Documentation: admin-guide: correct spelling
> [PATCH 2/9] Documentation: driver-api: correct spelling
applied
> [PATCH 3/9] Documentation: hwmon: correct spelling
> [PATCH 4/9] Documentation: networking: correct spelling
> [PATCH 5/9] Documentation: RCU: correct spelling
These have been taken up elsewhere
> [PATCH 6/9] Documentation: scsi/ChangeLog*: correct spelling
> [PATCH 7/9] Documentation: scsi: correct spelling
I've left these for the SCSI folks for now. Do we *really* want to be
fixing spelling in ChangeLog files from almost 20 years ago?
> [PATCH 8/9] Documentation: sparc: correct spelling
> [PATCH 9/9] Documentation: userspace-api: correct spelling
Applied.
Thanks,
jon
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/9] Documentation: correct lots of spelling errors (series 2)
2023-02-02 18:09 ` Jonathan Corbet
@ 2023-02-02 18:33 ` Randy Dunlap
2023-02-02 18:39 ` [dm-devel] " Bart Van Assche
0 siblings, 1 reply; 11+ messages in thread
From: Randy Dunlap @ 2023-02-02 18:33 UTC (permalink / raw)
To: Jonathan Corbet, linux-kernel
Cc: linux-doc, Tejun Heo, Zefan Li, Johannes Weiner, cgroups,
Alasdair Kergon, Mike Snitzer, dm-devel, Mauro Carvalho Chehab,
linux-media, linux-mm, Dan Williams, Vishal Verma, Dave Jiang,
nvdimm, Vinod Koul, dmaengine, Song Liu, linux-raid,
Greg Kroah-Hartman, linux-usb, Jean Delvare, Guenter Roeck,
linux-hwmon, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, Paul E. McKenney,
Frederic Weisbecker, Neeraj Upadhyay, Josh Triplett, rcu,
James E.J. Bottomley, Martin K. Petersen, linux-scsi, sparclinux
On 2/2/23 10:09, Jonathan Corbet wrote:
> Randy Dunlap <rdunlap@infradead.org> writes:
>
>> Maintainers of specific kernel subsystems are only Cc-ed on their
>> respective patches, not the entire series. [if all goes well]
>>
>> These patches are based on linux-next-20230127.
>
> So I've applied a bunch of these
>
>> [PATCH 6/9] Documentation: scsi/ChangeLog*: correct spelling
>> [PATCH 7/9] Documentation: scsi: correct spelling
>
> I've left these for the SCSI folks for now. Do we *really* want to be
> fixing spelling in ChangeLog files from almost 20 years ago?
That's why I made it a separate patch -- so the SCSI folks can decide that...
--
~Randy
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dm-devel] [PATCH 0/9] Documentation: correct lots of spelling errors (series 2)
2023-02-02 18:33 ` Randy Dunlap
@ 2023-02-02 18:39 ` Bart Van Assche
2023-02-02 18:46 ` Jonathan Corbet
0 siblings, 1 reply; 11+ messages in thread
From: Bart Van Assche @ 2023-02-02 18:39 UTC (permalink / raw)
To: Randy Dunlap, Jonathan Corbet, linux-kernel
Cc: nvdimm, linux-doc, Song Liu, dm-devel, netdev, Zefan Li,
sparclinux, Neeraj Upadhyay, Alasdair Kergon, Dave Jiang,
linux-scsi, Vishal Verma, Jakub Kicinski, Paolo Abeni,
James E.J. Bottomley, Guenter Roeck, linux-media, Jean Delvare,
Paul E. McKenney, Frederic Weisbecker, Mike Snitzer,
Josh Triplett, linux-raid, Tejun Heo, Jiri Pirko, cgroups,
Dan Williams, Mauro Carvalho Chehab, linux-hwmon, rcu,
Martin K. Petersen, linux-mm, Greg Kroah-Hartman, linux-usb,
Eric Dumazet, Vinod Koul, Johannes Weiner, dmaengine,
David S. Miller
On 2/2/23 10:33, Randy Dunlap wrote:
> On 2/2/23 10:09, Jonathan Corbet wrote:
>> Randy Dunlap <rdunlap@infradead.org> writes:
>>> [PATCH 6/9] Documentation: scsi/ChangeLog*: correct spelling
>>> [PATCH 7/9] Documentation: scsi: correct spelling
>>
>> I've left these for the SCSI folks for now. Do we *really* want to be
>> fixing spelling in ChangeLog files from almost 20 years ago?
>
> That's why I made it a separate patch -- so the SCSI folks can decide that...
How about removing the Documentation/scsi/ChangeLog.* files? I'm not
sure these changelogs are still useful since these duplicate information
that is already available in the output of git log ${driver_directory}.
Thanks,
Bart.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dm-devel] [PATCH 0/9] Documentation: correct lots of spelling errors (series 2)
2023-02-02 18:39 ` [dm-devel] " Bart Van Assche
@ 2023-02-02 18:46 ` Jonathan Corbet
2023-02-02 18:54 ` James Bottomley
0 siblings, 1 reply; 11+ messages in thread
From: Jonathan Corbet @ 2023-02-02 18:46 UTC (permalink / raw)
To: Bart Van Assche, Randy Dunlap, linux-kernel
Cc: nvdimm, linux-doc, Song Liu, dm-devel, netdev, Zefan Li,
sparclinux, Neeraj Upadhyay, Alasdair Kergon, Dave Jiang,
linux-scsi, Vishal Verma, Jakub Kicinski, Paolo Abeni,
James E.J. Bottomley, Guenter Roeck, linux-media, Jean Delvare,
Paul E. McKenney, Frederic Weisbecker, Mike Snitzer,
Josh Triplett, linux-raid, Tejun Heo, Jiri Pirko, cgroups,
Dan Williams, Mauro Carvalho Chehab, linux-hwmon, rcu,
Martin K. Petersen, linux-mm, Greg Kroah-Hartman, linux-usb,
Eric Dumazet, Vinod Koul, Johannes Weiner, dmaengine,
David S. Miller
Bart Van Assche <bvanassche@acm.org> writes:
> On 2/2/23 10:33, Randy Dunlap wrote:
>> On 2/2/23 10:09, Jonathan Corbet wrote:
>>> Randy Dunlap <rdunlap@infradead.org> writes:
>>>> [PATCH 6/9] Documentation: scsi/ChangeLog*: correct spelling
>>>> [PATCH 7/9] Documentation: scsi: correct spelling
>>>
>>> I've left these for the SCSI folks for now. Do we *really* want to be
>>> fixing spelling in ChangeLog files from almost 20 years ago?
>>
>> That's why I made it a separate patch -- so the SCSI folks can decide that...
>
> How about removing the Documentation/scsi/ChangeLog.* files? I'm not
> sure these changelogs are still useful since these duplicate information
> that is already available in the output of git log ${driver_directory}.
Actually, the information in those files mostly predates the git era, so
you won't find it that way. I *still* question their value, though...
jon
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dm-devel] [PATCH 0/9] Documentation: correct lots of spelling errors (series 2)
2023-02-02 18:46 ` Jonathan Corbet
@ 2023-02-02 18:54 ` James Bottomley
0 siblings, 0 replies; 11+ messages in thread
From: James Bottomley @ 2023-02-02 18:54 UTC (permalink / raw)
To: Jonathan Corbet, Bart Van Assche, Randy Dunlap, linux-kernel
Cc: nvdimm, linux-doc, Song Liu, dm-devel, netdev, Zefan Li,
sparclinux, Neeraj Upadhyay, Alasdair Kergon, Dave Jiang,
linux-scsi, Vishal Verma, Jakub Kicinski, Paolo Abeni,
Guenter Roeck, linux-media, Jean Delvare, Paul E. McKenney,
Frederic Weisbecker, Mike Snitzer, Josh Triplett, linux-raid,
Tejun Heo, Jiri Pirko, cgroups, Dan Williams,
Mauro Carvalho Chehab, linux-hwmon, rcu, Martin K. Petersen,
linux-mm, Greg Kroah-Hartman, linux-usb, Eric Dumazet, Vinod Koul,
Johannes Weiner, dmaengine, David S. Miller
On Thu, 2023-02-02 at 11:46 -0700, Jonathan Corbet wrote:
> Bart Van Assche <bvanassche@acm.org> writes:
>
> > On 2/2/23 10:33, Randy Dunlap wrote:
> > > On 2/2/23 10:09, Jonathan Corbet wrote:
> > > > Randy Dunlap <rdunlap@infradead.org> writes:
> > > > > [PATCH 6/9] Documentation: scsi/ChangeLog*: correct
> > > > > spelling
> > > > > [PATCH 7/9] Documentation: scsi: correct spelling
> > > >
> > > > I've left these for the SCSI folks for now. Do we *really*
> > > > want to be
> > > > fixing spelling in ChangeLog files from almost 20 years ago?
> > >
> > > That's why I made it a separate patch -- so the SCSI folks can
> > > decide that...
> >
> > How about removing the Documentation/scsi/ChangeLog.* files? I'm
> > not sure these changelogs are still useful since these duplicate
> > information that is already available in the output of git log
> > ${driver_directory}.
>
> Actually, the information in those files mostly predates the git era,
> so you won't find it that way. I *still* question their value,
> though...
In the pre-source control days they were the answer to the GPLv2
Section 2 requirement to " carry prominent notices stating that you
changed the files and the date of any change."
If you remove the files you may run afoul of the GPLv2 Section 1
requirement to "keep intact all the notices that refer to this
License". Of course, nowadays we assume the source control does this
for us, so people rarely think of these requirements, but for files
that predate source control I think you need to consider the licence
implications.
James
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: (subset) [PATCH 0/9] Documentation: correct lots of spelling errors (series 2)
2023-01-29 23:10 [PATCH 0/9] Documentation: correct lots of spelling errors (series 2) Randy Dunlap
` (2 preceding siblings ...)
2023-02-02 18:09 ` Jonathan Corbet
@ 2023-02-14 16:57 ` Martin K. Petersen
3 siblings, 0 replies; 11+ messages in thread
From: Martin K. Petersen @ 2023-02-14 16:57 UTC (permalink / raw)
To: linux-kernel, Randy Dunlap
Cc: Martin K . Petersen, Jonathan Corbet, linux-doc, Tejun Heo,
Zefan Li, Johannes Weiner, cgroups, Alasdair Kergon, Mike Snitzer,
dm-devel, Mauro Carvalho Chehab, linux-media, linux-mm,
Dan Williams, Vishal Verma, Dave Jiang, nvdimm, Vinod Koul,
dmaengine, Song Liu, linux-raid, Greg Kroah-Hartman, linux-usb,
Jean Delvare, Guenter Roeck, linux-hwmon, Jiri Pirko,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, Paul E. McKenney, Frederic Weisbecker, Neeraj Upadhyay,
Josh Triplett, rcu, James E.J. Bottomley, linux-scsi, sparclinux
On Sun, 29 Jan 2023 15:10:44 -0800, Randy Dunlap wrote:
> Maintainers of specific kernel subsystems are only Cc-ed on their
> respective patches, not the entire series. [if all goes well]
>
> These patches are based on linux-next-20230127.
>
>
> [PATCH 1/9] Documentation: admin-guide: correct spelling
> [PATCH 2/9] Documentation: driver-api: correct spelling
> [PATCH 3/9] Documentation: hwmon: correct spelling
> [PATCH 4/9] Documentation: networking: correct spelling
> [PATCH 5/9] Documentation: RCU: correct spelling
> [PATCH 6/9] Documentation: scsi/ChangeLog*: correct spelling
> [PATCH 7/9] Documentation: scsi: correct spelling
> [PATCH 8/9] Documentation: sparc: correct spelling
> [PATCH 9/9] Documentation: userspace-api: correct spelling
>
> [...]
Applied to 6.3/scsi-queue, thanks!
[6/9] Documentation: scsi/ChangeLog*: correct spelling
https://git.kernel.org/mkp/scsi/c/685d5ef436a9
[7/9] Documentation: scsi: correct spelling
https://git.kernel.org/mkp/scsi/c/cf065a7da517
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2023-02-14 16:59 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-01-29 23:10 [PATCH 0/9] Documentation: correct lots of spelling errors (series 2) Randy Dunlap
2023-01-29 23:10 ` [PATCH 5/9] Documentation: RCU: correct spelling Randy Dunlap
2023-01-30 5:24 ` Paul E. McKenney
2023-01-31 12:10 ` [PATCH 0/9] Documentation: correct lots of spelling errors (series 2) patchwork-bot+netdevbpf
2023-01-31 12:17 ` Paolo Abeni
2023-02-02 18:09 ` Jonathan Corbet
2023-02-02 18:33 ` Randy Dunlap
2023-02-02 18:39 ` [dm-devel] " Bart Van Assche
2023-02-02 18:46 ` Jonathan Corbet
2023-02-02 18:54 ` James Bottomley
2023-02-14 16:57 ` (subset) " Martin K. Petersen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox