On 2/27/21 5:02 PM, Bhaskar Chowdhury wrote: > > Few spelling fixes throughout the file. > > Signed-off-by: Bhaskar Chowdhury <[email protected]>
Acked-by: Randy Dunlap <[email protected]> > --- > Changes from V1: > Fixed the subject line typo. > Measured unwanted blank lines insertion. > > fs/dlm/lock.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c > index 002123efc6b0..b00001c36ed5 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. > @@ -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
