On 3/15/21 10:27 PM, Bhaskar Chowdhury wrote: > > Trivial typo fixes throughout the file. > > cc: triv...@vger.kernel.org > > Signed-off-by: Bhaskar Chowdhury <unixbhas...@gmail.com>
Acked-by: Randy Dunlap <rdun...@infradead.org> > --- > 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 > -- -- ~Randy