[23/24] Documentation: x86: correct spelling

  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(-)
  

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
  

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
  

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
  

> > 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>