Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "John B. Wyatt IV" <jbwyatt4@gmail.com>
To:     "' Joel Fernandes (Google)" <joel@joelfernandes.org>,
        Nishanth Aravamudan <naravamudan@digitalocean.com>,
        Julien Desfossez <jdesfossez@digitalocean.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Vineeth Pillai <viremana@linux.microsoft.com>,
        Aaron Lu <aaron.lwe@gmail.com>,
        Aubrey Li <aubrey.intel@gmail.com>, tglx@linutronix.de,
        linux-kernel@vger.kernel.org, mingo@kernel.org,
        torvalds@linux-foundation.org, fweisbec@gmail.com,
        keescook@chromium.org, kerrnel@google.com,
        Phil Auld <pauld@redhat.com>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Mel Gorman <mgorman@techsingularity.net>,
        Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
        Paolo Bonzini <pbonzini@redhat.com>, vineeth@bitbyteword.org,
        Chen Yu <yu.c.chen@intel.com>,
        Christian Brauner <christian.brauner@ubuntu.com>,
        Agata Gruza <agata.gruza@intel.com>,
        Antonio Gomez Iglesias <antonio.gomez.iglesias@intel.com>,
        graf@amazon.com, konrad.wilk@oracle.com, dfaggioli@suse.com,
        pjt@google.com, rostedt@goodmis.org, derkling@google.com,
        benbjiang@tencent.com,
        Alexandre Chartre <alexandre.chartre@oracle.com>,
        James.Bottomley@hansenpartnership.com, OWeisse@umich.edu,
        Dhaval Giani <dhaval.giani@oracle.com>,
        Junaid Shahid <junaids@google.com>, jsbarnes@google.com,
        chris.hyser@oracle.com, Aubrey Li <aubrey.li@linux.intel.com>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        Tim Chen ' <tim.c.chen@intel.com>
Cc:     "John B. Wyatt IV" <jbwyatt4@gmail.com>
Subject: [PATCH 1/8] sched: Correct misspellings in core-scheduling.rst
Date:   Wed, 28 Oct 2020 05:19:10 -0700
Message-Id: <20201028121917.635203-2-jbwyatt4@gmail.com>
In-Reply-To: <20201028121917.635203-1-jbwyatt4@gmail.com>
References: <20201028121917.635203-1-jbwyatt4@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

'priorty', 'guarenteed', 'guarentee' should be: priority, guaranteed,
guarantee.

Issue reported by checkpatch.

Signed-off-by: John B. Wyatt IV <jbwyatt4@gmail.com>
---
 Documentation/admin-guide/hw-vuln/core-scheduling.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/admin-guide/hw-vuln/core-scheduling.rst b/Documentation/admin-guide/hw-vuln/core-scheduling.rst
index eacafbb8fa3f..638d0f3c1c09 100644
--- a/Documentation/admin-guide/hw-vuln/core-scheduling.rst
+++ b/Documentation/admin-guide/hw-vuln/core-scheduling.rst
@@ -161,7 +161,7 @@ priority task is not trusted with respect to the core wide highest priority
 task.  If a sibling does not have a trusted task to run, it will be forced idle
 by the scheduler(idle thread is scheduled to run).
 
-When the highest priorty task is selected to run, a reschedule-IPI is sent to
+When the highest priority task is selected to run, a reschedule-IPI is sent to
 the sibling to force it into idle. This results in 4 cases which need to be
 considered depending on whether a VM or a regular usermode process was running
 on either HT::
@@ -223,9 +223,9 @@ Also this does nothing about syscall entries.
 3. Kernel Address Space Isolation
 #################################
 System calls could run in a much restricted address space which is
-guarenteed not to leak any sensitive data. There are practical limitation in
+guaranteed not to leak any sensitive data. There are practical limitation in
 implementing this - the main concern being how to decide on an address space
-that is guarenteed to not have any sensitive data.
+that is guaranteed to not have any sensitive data.
 
 4. Limited cookie-based protection
 ##################################
@@ -251,7 +251,7 @@ outside. Tasks outside the group also don't trust tasks within.
 
 Limitations
 -----------
-Core scheduling tries to guarentee that only trusted tasks run concurrently on a
+Core scheduling tries to guarantee that only trusted tasks run concurrently on a
 core. But there could be small window of time during which untrusted tasks run
 concurrently or kernel could be running concurrently with a task not trusted by
 kernel.
-- 
2.28.0