Few spelling fixes throughout the file.
Signed-off-by: Bhaskar Chowdhury <[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 -- 2.26.2
