* [PATCH 23/24] Documentation: x86: correct spelling
2023-02-09 7:13 [PATCH 00/24 v2] Documentation: correct lots of spelling errors (series 1) Randy Dunlap
@ 2023-02-09 7:13 ` Randy Dunlap
2023-02-09 23:22 ` Reinette Chatre
` (2 more replies)
2023-02-11 0:30 ` [PATCH 00/24 v2] Documentation: correct lots of spelling errors (series 1) patchwork-bot+netdevbpf
2023-06-26 6:56 ` Krzysztof Wilczyński
2 siblings, 3 replies; 8+ messages in thread
From: Randy Dunlap @ 2023-02-09 7:13 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Jarkko Sakkinen, linux-sgx, Fenghua Yu,
Reinette Chatre, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
x86, Jonathan Corbet, linux-doc
Correct spelling problems for Documentation/x86/ as reported
by codespell.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Jarkko Sakkinen <jarkko@kernel.org>
Cc: linux-sgx@vger.kernel.org
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
---
Documentation/x86/boot.rst | 2 +-
Documentation/x86/buslock.rst | 2 +-
Documentation/x86/mds.rst | 2 +-
Documentation/x86/resctrl.rst | 2 +-
Documentation/x86/sgx.rst | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff -- a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
--- a/Documentation/x86/boot.rst
+++ b/Documentation/x86/boot.rst
@@ -1105,7 +1105,7 @@ The kernel command line should not be lo
code, nor should it be located in high memory.
-Sample Boot Configuartion
+Sample Boot Configuration
=========================
As a sample configuration, assume the following layout of the real
diff -- a/Documentation/x86/buslock.rst b/Documentation/x86/buslock.rst
--- a/Documentation/x86/buslock.rst
+++ b/Documentation/x86/buslock.rst
@@ -32,7 +32,7 @@ mechanisms to detect split locks and bus
--------------------------------------
Beginning with the Tremont Atom CPU split lock operations may raise an
-Alignment Check (#AC) exception when a split lock operation is attemped.
+Alignment Check (#AC) exception when a split lock operation is attempted.
#DB exception for bus lock detection
------------------------------------
diff -- a/Documentation/x86/mds.rst b/Documentation/x86/mds.rst
--- a/Documentation/x86/mds.rst
+++ b/Documentation/x86/mds.rst
@@ -60,7 +60,7 @@ needed for exploiting MDS requires:
data
The existence of such a construct in the kernel cannot be excluded with
-100% certainty, but the complexity involved makes it extremly unlikely.
+100% certainty, but the complexity involved makes it extremely unlikely.
There is one exception, which is untrusted BPF. The functionality of
untrusted BPF is limited, but it needs to be thoroughly investigated
diff -- a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst
--- a/Documentation/x86/resctrl.rst
+++ b/Documentation/x86/resctrl.rst
@@ -487,7 +487,7 @@ this would be dependent on number of cor
depending on # of threads:
For the same SKU in #1, a 'single thread, with 10% bandwidth' and '4
-thread, with 10% bandwidth' can consume upto 10GBps and 40GBps although
+thread, with 10% bandwidth' can consume up to 10GBps and 40GBps although
they have same percentage bandwidth of 10%. This is simply because as
threads start using more cores in an rdtgroup, the actual bandwidth may
increase or vary although user specified bandwidth percentage is same.
diff -- a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst
--- a/Documentation/x86/sgx.rst
+++ b/Documentation/x86/sgx.rst
@@ -245,7 +245,7 @@ SGX will likely become unusable because
limited. However, while this may be fatal to SGX, the rest of the kernel
is unlikely to be impacted and should continue to work.
-As a result, when this happpens, user should stop running any new
+As a result, when this happens, the user should stop running any new
SGX workloads, (or just any new workloads), and migrate all valuable
workloads. Although a machine reboot can recover all EPC memory, the bug
should be reported to Linux developers.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH 23/24] Documentation: x86: correct spelling
2023-02-09 7:13 ` [PATCH 23/24] Documentation: x86: correct spelling Randy Dunlap
@ 2023-02-09 23:22 ` Reinette Chatre
2023-02-10 3:55 ` Jarkko Sakkinen
2023-02-10 4:19 ` Fenghua Yu
2 siblings, 0 replies; 8+ messages in thread
From: Reinette Chatre @ 2023-02-09 23:22 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel
Cc: Jarkko Sakkinen, linux-sgx, Fenghua Yu, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, x86, Jonathan Corbet, linux-doc
Hi Randy,
On 2/8/2023 11:13 PM, Randy Dunlap wrote:
> Correct spelling problems for Documentation/x86/ as reported
> by codespell.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Jarkko Sakkinen <jarkko@kernel.org>
> Cc: linux-sgx@vger.kernel.org
> Cc: Fenghua Yu <fenghua.yu@intel.com>
> Cc: Reinette Chatre <reinette.chatre@intel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: x86@kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-doc@vger.kernel.org
> ---
> Documentation/x86/boot.rst | 2 +-
> Documentation/x86/buslock.rst | 2 +-
> Documentation/x86/mds.rst | 2 +-
> Documentation/x86/resctrl.rst | 2 +-
> Documentation/x86/sgx.rst | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
...
> diff -- a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst
> --- a/Documentation/x86/resctrl.rst
> +++ b/Documentation/x86/resctrl.rst
> @@ -487,7 +487,7 @@ this would be dependent on number of cor
> depending on # of threads:
>
> For the same SKU in #1, a 'single thread, with 10% bandwidth' and '4
> -thread, with 10% bandwidth' can consume upto 10GBps and 40GBps although
> +thread, with 10% bandwidth' can consume up to 10GBps and 40GBps although
> they have same percentage bandwidth of 10%. This is simply because as
> threads start using more cores in an rdtgroup, the actual bandwidth may
> increase or vary although user specified bandwidth percentage is same.
Acked-by: Reinette Chatre <reinette.chatre@intel.com> #resctrl
Thank you very much
Reinette
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 23/24] Documentation: x86: correct spelling
2023-02-09 7:13 ` [PATCH 23/24] Documentation: x86: correct spelling Randy Dunlap
2023-02-09 23:22 ` Reinette Chatre
@ 2023-02-10 3:55 ` Jarkko Sakkinen
2023-02-14 1:23 ` Huang, Kai
2023-02-10 4:19 ` Fenghua Yu
2 siblings, 1 reply; 8+ messages in thread
From: Jarkko Sakkinen @ 2023-02-10 3:55 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-kernel, linux-sgx, Fenghua Yu, Reinette Chatre,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86,
Jonathan Corbet, linux-doc
On Wed, Feb 08, 2023 at 11:13:59PM -0800, Randy Dunlap wrote:
> Correct spelling problems for Documentation/x86/ as reported
> by codespell.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Jarkko Sakkinen <jarkko@kernel.org>
> Cc: linux-sgx@vger.kernel.org
> Cc: Fenghua Yu <fenghua.yu@intel.com>
> Cc: Reinette Chatre <reinette.chatre@intel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: x86@kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-doc@vger.kernel.org
> ---
> Documentation/x86/boot.rst | 2 +-
> Documentation/x86/buslock.rst | 2 +-
> Documentation/x86/mds.rst | 2 +-
> Documentation/x86/resctrl.rst | 2 +-
> Documentation/x86/sgx.rst | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff -- a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
> --- a/Documentation/x86/boot.rst
> +++ b/Documentation/x86/boot.rst
> @@ -1105,7 +1105,7 @@ The kernel command line should not be lo
> code, nor should it be located in high memory.
>
>
> -Sample Boot Configuartion
> +Sample Boot Configuration
> =========================
>
> As a sample configuration, assume the following layout of the real
> diff -- a/Documentation/x86/buslock.rst b/Documentation/x86/buslock.rst
> --- a/Documentation/x86/buslock.rst
> +++ b/Documentation/x86/buslock.rst
> @@ -32,7 +32,7 @@ mechanisms to detect split locks and bus
> --------------------------------------
>
> Beginning with the Tremont Atom CPU split lock operations may raise an
> -Alignment Check (#AC) exception when a split lock operation is attemped.
> +Alignment Check (#AC) exception when a split lock operation is attempted.
>
> #DB exception for bus lock detection
> ------------------------------------
> diff -- a/Documentation/x86/mds.rst b/Documentation/x86/mds.rst
> --- a/Documentation/x86/mds.rst
> +++ b/Documentation/x86/mds.rst
> @@ -60,7 +60,7 @@ needed for exploiting MDS requires:
> data
>
> The existence of such a construct in the kernel cannot be excluded with
> -100% certainty, but the complexity involved makes it extremly unlikely.
> +100% certainty, but the complexity involved makes it extremely unlikely.
>
> There is one exception, which is untrusted BPF. The functionality of
> untrusted BPF is limited, but it needs to be thoroughly investigated
> diff -- a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst
> --- a/Documentation/x86/resctrl.rst
> +++ b/Documentation/x86/resctrl.rst
> @@ -487,7 +487,7 @@ this would be dependent on number of cor
> depending on # of threads:
>
> For the same SKU in #1, a 'single thread, with 10% bandwidth' and '4
> -thread, with 10% bandwidth' can consume upto 10GBps and 40GBps although
> +thread, with 10% bandwidth' can consume up to 10GBps and 40GBps although
> they have same percentage bandwidth of 10%. This is simply because as
> threads start using more cores in an rdtgroup, the actual bandwidth may
> increase or vary although user specified bandwidth percentage is same.
> diff -- a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst
> --- a/Documentation/x86/sgx.rst
> +++ b/Documentation/x86/sgx.rst
> @@ -245,7 +245,7 @@ SGX will likely become unusable because
> limited. However, while this may be fatal to SGX, the rest of the kernel
> is unlikely to be impacted and should continue to work.
>
> -As a result, when this happpens, user should stop running any new
> +As a result, when this happens, the user should stop running any new
> SGX workloads, (or just any new workloads), and migrate all valuable
> workloads. Although a machine reboot can recover all EPC memory, the bug
> should be reported to Linux developers.
Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
BR, Jarkko
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 23/24] Documentation: x86: correct spelling
2023-02-10 3:55 ` Jarkko Sakkinen
@ 2023-02-14 1:23 ` Huang, Kai
0 siblings, 0 replies; 8+ messages in thread
From: Huang, Kai @ 2023-02-14 1:23 UTC (permalink / raw)
To: jarkko, rdunlap
Cc: corbet, linux-sgx, bp, x86, Chatre, Reinette, linux-kernel, tglx,
linux-doc, mingo, Yu, Fenghua
> > diff -- a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst
> > --- a/Documentation/x86/sgx.rst
> > +++ b/Documentation/x86/sgx.rst
> > @@ -245,7 +245,7 @@ SGX will likely become unusable because
> > limited. However, while this may be fatal to SGX, the rest of the kernel
> > is unlikely to be impacted and should continue to work.
> >
> > -As a result, when this happpens, user should stop running any new
> > +As a result, when this happens, the user should stop running any new
> > SGX workloads, (or just any new workloads), and migrate all valuable
> > workloads. Although a machine reboot can recover all EPC memory, the bug
> > should be reported to Linux developers.
>
>
> Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
>
> BR, Jarkko
For SGX part:
Acked-by: Kai Huang <kai.huang@intel.com>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 23/24] Documentation: x86: correct spelling
2023-02-09 7:13 ` [PATCH 23/24] Documentation: x86: correct spelling Randy Dunlap
2023-02-09 23:22 ` Reinette Chatre
2023-02-10 3:55 ` Jarkko Sakkinen
@ 2023-02-10 4:19 ` Fenghua Yu
2 siblings, 0 replies; 8+ messages in thread
From: Fenghua Yu @ 2023-02-10 4:19 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel
Cc: Jarkko Sakkinen, linux-sgx, Reinette Chatre, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, x86, Jonathan Corbet, linux-doc
On 2/8/23 23:13, Randy Dunlap wrote:
> Correct spelling problems for Documentation/x86/ as reported
> by codespell.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Jarkko Sakkinen <jarkko@kernel.org>
> Cc: linux-sgx@vger.kernel.org
> Cc: Fenghua Yu <fenghua.yu@intel.com>
> Cc: Reinette Chatre <reinette.chatre@intel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: x86@kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-doc@vger.kernel.org
> ---
> Documentation/x86/boot.rst | 2 +-
> Documentation/x86/buslock.rst | 2 +-
> Documentation/x86/mds.rst | 2 +-
> Documentation/x86/resctrl.rst | 2 +-
> Documentation/x86/sgx.rst | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff -- a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
> --- a/Documentation/x86/boot.rst
> +++ b/Documentation/x86/boot.rst
> @@ -1105,7 +1105,7 @@ The kernel command line should not be lo
> code, nor should it be located in high memory.
>
>
> -Sample Boot Configuartion
> +Sample Boot Configuration
> =========================
>
> As a sample configuration, assume the following layout of the real
> diff -- a/Documentation/x86/buslock.rst b/Documentation/x86/buslock.rst
> --- a/Documentation/x86/buslock.rst
> +++ b/Documentation/x86/buslock.rst
> @@ -32,7 +32,7 @@ mechanisms to detect split locks and bus
> --------------------------------------
>
> Beginning with the Tremont Atom CPU split lock operations may raise an
> -Alignment Check (#AC) exception when a split lock operation is attemped.
> +Alignment Check (#AC) exception when a split lock operation is attempted.
>
> #DB exception for bus lock detection
> ------------------------------------
> diff -- a/Documentation/x86/mds.rst b/Documentation/x86/mds.rst
> --- a/Documentation/x86/mds.rst
> +++ b/Documentation/x86/mds.rst
> @@ -60,7 +60,7 @@ needed for exploiting MDS requires:
> data
>
> The existence of such a construct in the kernel cannot be excluded with
> -100% certainty, but the complexity involved makes it extremly unlikely.
> +100% certainty, but the complexity involved makes it extremely unlikely.
>
> There is one exception, which is untrusted BPF. The functionality of
> untrusted BPF is limited, but it needs to be thoroughly investigated
> diff -- a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst
> --- a/Documentation/x86/resctrl.rst
> +++ b/Documentation/x86/resctrl.rst
> @@ -487,7 +487,7 @@ this would be dependent on number of cor
> depending on # of threads:
>
> For the same SKU in #1, a 'single thread, with 10% bandwidth' and '4
> -thread, with 10% bandwidth' can consume upto 10GBps and 40GBps although
> +thread, with 10% bandwidth' can consume up to 10GBps and 40GBps although
> they have same percentage bandwidth of 10%. This is simply because as
> threads start using more cores in an rdtgroup, the actual bandwidth may
> increase or vary although user specified bandwidth percentage is same.
> diff -- a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst
> --- a/Documentation/x86/sgx.rst
> +++ b/Documentation/x86/sgx.rst
> @@ -245,7 +245,7 @@ SGX will likely become unusable because
> limited. However, while this may be fatal to SGX, the rest of the kernel
> is unlikely to be impacted and should continue to work.
>
> -As a result, when this happpens, user should stop running any new
> +As a result, when this happens, the user should stop running any new
> SGX workloads, (or just any new workloads), and migrate all valuable
> workloads. Although a machine reboot can recover all EPC memory, the bug
> should be reported to Linux developers.
Acked-by: Fenghua Yu <fenghua.yu@intel.com>
Thanks.
-Fenghua
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 00/24 v2] Documentation: correct lots of spelling errors (series 1)
2023-02-09 7:13 [PATCH 00/24 v2] Documentation: correct lots of spelling errors (series 1) Randy Dunlap
2023-02-09 7:13 ` [PATCH 23/24] Documentation: x86: correct spelling Randy Dunlap
@ 2023-02-11 0:30 ` patchwork-bot+netdevbpf
2023-06-26 6:56 ` Krzysztof Wilczyński
2 siblings, 0 replies; 8+ messages in thread
From: patchwork-bot+netdevbpf @ 2023-02-11 0:30 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-kernel, corbet, linux, axboe, olteanv, steffen.klassert,
daniel.m.jordan, akinobu.mita, deller, dmitry.torokhov, rydberg,
isdn, jikos, mbenes, pmladek, jpoimboe, peterz, mingo, will,
jglisse, naoya.horiguchi, linmiaohe, jonas, stefan.kristiansson,
shorne, bhelgaas, lpieralisi, maz, mpe, hca, gor, agordeev,
juri.lelli, vincent.guittot, dhowells, jarkko, paul, jmorris,
serge, bristot, rostedt, mhiramat, mathieu.poirier,
suzuki.poulose, zbr, fenghua.yu, reinette.chatre, tglx, bp,
chris, jcmvbkbc, coresight, dri-devel, keyrings, linux-block,
linux-crypto, linux-doc, linux-fbdev, linux-input, linux-pci,
linux-s390, linux-scsi, linux-sgx, linux-trace-devel,
linux-trace-kernel, live-patching, linux-security-module,
linux-usb, netdev, linux-mm, openrisc, linux-arm-kernel,
linux-xtensa, linuxppc-dev, x86
Hello:
This series was applied to netdev/net-next.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 8 Feb 2023 23:13:36 -0800 you wrote:
> Correct many spelling errors in Documentation/ as reported by codespell.
>
> Maintainers of specific kernel subsystems are only Cc-ed on their
> respective patches, not the entire series.
>
> These patches are based on linux-next-20230209.
>
> [...]
Here is the summary with links:
- [03/24] Documentation: core-api: correct spelling
(no matching commit)
- [08/24] Documentation: isdn: correct spelling
https://git.kernel.org/netdev/net-next/c/d12f9ad02806
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] 8+ messages in thread* Re: [PATCH 00/24 v2] Documentation: correct lots of spelling errors (series 1)
2023-02-09 7:13 [PATCH 00/24 v2] Documentation: correct lots of spelling errors (series 1) Randy Dunlap
2023-02-09 7:13 ` [PATCH 23/24] Documentation: x86: correct spelling Randy Dunlap
2023-02-11 0:30 ` [PATCH 00/24 v2] Documentation: correct lots of spelling errors (series 1) patchwork-bot+netdevbpf
@ 2023-06-26 6:56 ` Krzysztof Wilczyński
2 siblings, 0 replies; 8+ messages in thread
From: Krzysztof Wilczyński @ 2023-06-26 6:56 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-kernel, Jonathan Corbet, Russell King, Jens Axboe,
Vladimir Oltean, Steffen Klassert, Daniel Jordan, Akinobu Mita,
Helge Deller, Dmitry Torokhov, Henrik Rydberg, Karsten Keil,
Jiri Kosina, Miroslav Benes, Petr Mladek, Josh Poimboeuf,
Peter Zijlstra, Ingo Molnar, Will Deacon,
Jérôme Glisse, Naoya Horiguchi, Miaohe Lin, Jonas Bonn,
Stefan Kristiansson, Stafford Horne, Bjorn Helgaas,
Lorenzo Pieralisi, Marc Zyngier, Michael Ellerman,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev, Juri Lelli,
Vincent Guittot, David Howells, Jarkko Sakkinen, Paul Moore,
James Morris, Serge E. Hallyn, Daniel Bristot de Oliveira,
Steven Rostedt, Masami Hiramatsu, Mathieu Poirier,
Suzuki K Poulose, Evgeniy Polyakov, Fenghua Yu, Reinette Chatre,
Thomas Gleixner, Borislav Petkov, Chris Zankel, Max Filippov,
coresight, dri-devel, keyrings, linux-block, linux-crypto,
linux-doc, linux-fbdev, linux-input, linux-pci, linux-s390,
linux-scsi, linux-sgx, linux-trace-devel, linux-trace-kernel,
live-patching, linux-security-module, linux-usb, netdev,
linux-mm, openrisc, linux-arm-kernel, linux-xtensa, linuxppc-dev,
x86
Hello,
> Correct many spelling errors in Documentation/ as reported by codespell.
>
> Maintainers of specific kernel subsystems are only Cc-ed on their
> respective patches, not the entire series.
>
> These patches are based on linux-next-20230209.
>
[...]
> [PATCH 13/24] Documentation: PCI: correct spelling
[...]
Applied to misc, thank you!
[1/1] Documentation: PCI: correct spelling
https://git.kernel.org/pci/pci/c/b58d6d89ae02
Krzysztof
^ permalink raw reply [flat|nested] 8+ messages in thread