locking: Fix comment typos

A few snuck through.

Signed-off-by: Ingo Molnar <mingo@kernel.org>

diff --git a/include/linux/lockdep_types.h b/include/linux/lockdep_types.h
index 2ec9ff5..3e726ac 100644 (file)
--- a/include/linux/lockdep_types.h
+++ b/include/linux/lockdep_types.h
@@ -52,7 +52,7 @@ enum lockdep_lock_type {
  * NR_LOCKDEP_CACHING_CLASSES ... Number of classes
  * cached in the instance of lockdep_map
  *
- * Currently main class (subclass == 0) and signle depth subclass
+ * Currently main class (subclass == 0) and single depth subclass
  * are cached in lockdep_map. This optimization is mainly targeting
  * on rq->lock. double_rq_lock() acquires this highly competitive with
  * single depth.

diff --git a/kernel/futex.c b/kernel/futex.c
index 4938a00..2f386f0 100644 (file)
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1874,7 +1874,7 @@ futex_proxy_trylock_atomic(u32 __user *pifutex, struct futex_hash_bucket *hb1,
         * If the caller intends to requeue more than 1 waiter to pifutex,
         * force futex_lock_pi_atomic() to set the FUTEX_WAITERS bit now,
         * as we have means to handle the possible fault.  If not, don't set
-        * the bit unecessarily as it will force the subsequent unlock to enter
+        * the bit unnecessarily as it will force the subsequent unlock to enter
         * the kernel.
         */
        top_waiter = futex_top_waiter(hb1, key1);
@@ -2103,7 +2103,7 @@ retry_private:
                        continue;
 
                /*
-                * FUTEX_WAIT_REQEUE_PI and FUTEX_CMP_REQUEUE_PI should always
+                * FUTEX_WAIT_REQUEUE_PI and FUTEX_CMP_REQUEUE_PI should always
                 * be paired with each other and no other futex ops.
                 *
                 * We should never be requeueing a futex_q with a pi_state,
@@ -2318,7 +2318,7 @@ retry:
 }
 
 /*
- * PI futexes can not be requeued and must remove themself from the
+ * PI futexes can not be requeued and must remove themselves from the
  * hash bucket. The hash bucket lock (i.e. lock_ptr) is held.
  */
 static void unqueue_me_pi(struct futex_q *q)
@@ -2903,7 +2903,7 @@ no_block:
         */
        res = fixup_owner(uaddr, &q, !ret);
        /*
-        * If fixup_owner() returned an error, proprogate that.  If it acquired
+        * If fixup_owner() returned an error, propagate that.  If it acquired
         * the lock, clear our -ETIMEDOUT or -EINTR.
         */
        if (res)
@@ -3280,7 +3280,7 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags,
                 */
                res = fixup_owner(uaddr2, &q, !ret);
                /*
-                * If fixup_owner() returned an error, proprogate that.  If it
+                * If fixup_owner() returned an error, propagate that.  If it
                 * acquired the lock, clear -ETIMEDOUT or -EINTR.
                 */
                if (res)
@@ -3678,7 +3678,7 @@ void futex_exec_release(struct task_struct *tsk)
 {
        /*
         * The state handling is done for consistency, but in the case of
-        * exec() there is no way to prevent futher damage as the PID stays
+        * exec() there is no way to prevent further damage as the PID stays
         * the same. But for the unlikely and arguably buggy case that a
         * futex is held on exec(), this provides at least as much state
         * consistency protection which is possible.