[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210316052732.682020-1-unixbhaskar@gmail.com>
Date: Tue, 16 Mar 2021 10:57:32 +0530
From: Bhaskar Chowdhury <unixbhaskar@...il.com>
To: ccaulfie@...hat.com, teigland@...hat.com, cluster-devel@...hat.com,
linux-kernel@...r.kernel.org
Cc: rdunlap@...radead.org, Bhaskar Chowdhury <unixbhaskar@...il.com>,
trivial@...r.kernel.org
Subject: [PATCH] dlm: Mundane typo fixes throughout the file lock.c
Trivial typo fixes throughout the file.
cc: trivial@...r.kernel.org
Signed-off-by: Bhaskar Chowdhury <unixbhaskar@...il.com>
---
fs/dlm/lock.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c
index 002123efc6b0..caadc426c8b4 100644
--- a/fs/dlm/lock.c
+++ b/fs/dlm/lock.c
@@ -91,7 +91,7 @@ static void del_timeout(struct dlm_lkb *lkb);
static void toss_rsb(struct kref *kref);
/*
- * Lock compatibilty matrix - thanks Steve
+ * Lock compatibility matrix - thanks Steve
* UN = Unlocked state. Not really a state, used as a flag
* PD = Padding. Used to make the matrix a nice power of two in size
* Other states are the same as the VMS DLM.
@@ -1535,7 +1535,7 @@ static int _remove_from_waiters(struct dlm_lkb *lkb, int mstype,
return -1;
}
- /* Remove for the convert reply, and premptively remove for the
+ /* Remove for the convert reply, and preemptively remove for the
cancel reply. A convert has been granted while there's still
an outstanding cancel on it (the cancel is moot and the result
in the cancel reply should be 0). We preempt the cancel reply
@@ -2357,14 +2357,14 @@ static int _can_be_granted(struct dlm_rsb *r, struct dlm_lkb *lkb, int now,
* 6-5: But the default algorithm for deciding whether to grant or
* queue conversion requests does not by itself guarantee that such
* requests are serviced on a "first come first serve" basis. This, in
- * turn, can lead to a phenomenon known as "indefinate postponement".
+ * turn, can lead to a phenomenon known as "indefinite postponement".
*
* 6-7: This issue is dealt with by using the optional QUECVT flag with
* the system service employed to request a lock conversion. This flag
* forces certain conversion requests to be queued, even if they are
* compatible with the granted modes of other locks on the same
* resource. Thus, the use of this flag results in conversion requests
- * being ordered on a "first come first servce" basis.
+ * being ordered on a "first come first serve" basis.
*
* DCT: This condition is all about new conversions being able to occur
* "in place" while the lock remains on the granted queue (assuming
--
2.30.2
Powered by blists - more mailing lists