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@xxxxxxxxxxxxx> > Cc: Jarkko Sakkinen <jarkko@xxxxxxxxxx> > Cc: linux-sgx@xxxxxxxxxxxxxxx > Cc: Fenghua Yu <fenghua.yu@xxxxxxxxx> > Cc: Reinette Chatre <reinette.chatre@xxxxxxxxx> > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Cc: Ingo Molnar <mingo@xxxxxxxxxx> > Cc: Borislav Petkov <bp@xxxxxxxxx> > Cc: x86@xxxxxxxxxx > Cc: Jonathan Corbet <corbet@xxxxxxx> > Cc: linux-doc@xxxxxxxxxxxxxxx > --- > 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@xxxxxxxxxx> BR, Jarkko
