diff --git a/unified-scheduler-pool/src/lib.rs b/unified-scheduler-pool/src/lib.rs
index 5c4f47ac7043f0..348b6bb0382258 100644
--- a/unified-scheduler-pool/src/lib.rs
+++ b/unified-scheduler-pool/src/lib.rs
@@ -757,7 +757,7 @@ impl<S: SpawnableScheduler<TH>, TH: TaskHandler> ThreadManager<S, TH> {
                         // There's something special called dummy_unblocked_task_receiver here.
                         // This odd pattern was needed to react to newly unblocked tasks from
                         // _not-crossbeam-channel_ event sources, precisely at the specified
-                        // precedence among other selectors, while delegating the conrol flow to
+                        // precedence among other selectors, while delegating the control flow to
                         // select_biased!.
                         //
                         // In this way, hot looping is avoided and overall control flow is much
@@ -1237,8 +1237,8 @@ mod tests {
         scheduler.pause_for_recent_blockhash();
         // transaction_count should remain same as scheduler should be bailing out.
         // That's because we're testing the serialized failing execution case in this test.
-        // However, currently threaded impl can't properly abort in this situtation..
-        // so, 1 should be observed, intead of 0.
+        // However, currently threaded impl can't properly abort in this situation..
+        // so, 1 should be observed, instead of 0.
         // Also note that bank.transaction_count() is generally racy by nature, because
         // blockstore_processor and unified_scheduler both tend to process non-conflicting batches
         // in parallel as part of the normal operation.
diff --git a/validator/src/bootstrap.rs b/validator/src/bootstrap.rs
index e94ead0f3834fb..63084741f03a3e 100644
--- a/validator/src/bootstrap.rs
+++ b/validator/src/bootstrap.rs
@@ -868,7 +868,7 @@ fn get_peer_snapshot_hashes(
         // being selected.  For example, if there are two peer snapshot hashes:
         // (A) full snapshot slot: 100, incremental snapshot slot: 160
         // (B) full snapshot slot: 150, incremental snapshot slot: None
-        // Then (A) has the highest overall snapshot slot.  But if we're not downlading and
+        // Then (A) has the highest overall snapshot slot.  But if we're not downloading and
         // incremental snapshot, (B) should be selected since it's full snapshot of 150 is highest.
         retain_peer_snapshot_hashes_with_highest_incremental_snapshot_slot(
             &mut peer_snapshot_hashes,