| Message ID | 20230209071400.31476-24-rdunlap@infradead.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Documentation: correct lots of spelling errors (series 1) | expand |
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>
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.
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(-)