On 2/27/21 3:33 PM, Bhaskar Chowdhury wrote: > > Few spelling fixes throughout the file. >
in Subject: s/fle/file/ > Signed-off-by: Bhaskar Chowdhury <[email protected]> > --- > fs/dlm/lock.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c > index 002123efc6b0..efcd84faca14 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. > @@ -594,7 +594,7 @@ static int find_rsb_dir(struct dlm_ls *ls, char *name, > int len, > error = dlm_search_rsb_tree(&ls->ls_rsbtbl[b].keep, name, len, &r); > if (error) > goto do_toss; > - > + stray change? > /* > * rsb is active, so we can't check master_nodeid without lock_rsb. > */ > @@ -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 > @@ -5745,7 +5745,7 @@ int dlm_recover_process_copy(struct dlm_ls *ls, struct > dlm_rcom *rc) > > log_debug(ls, "dlm_recover_process_copy %x remote %d %x %d", > lkid, rc->rc_header.h_nodeid, remid, result); > - > + stray change? > dlm_send_rcom_lock(r, lkb); > goto out; > case -EEXIST: > -- -- ~Randy
