On Sat, 2025-04-19 at 16:55 +0800, Li Lingfeng wrote: > This patch does minor comment cleanup: > - Fix spelling mistakes (e.g. "silibing" -> "sibling") > - Correct grammatical errors > No functional changes involved. > > Signed-off-by: Li Lingfeng <lilingfeng3@xxxxxxxxxx> > --- > fs/locks.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/fs/locks.c b/fs/locks.c > index 1619cddfa7a4..f06258216b31 100644 > --- a/fs/locks.c > +++ b/fs/locks.c > @@ -12,7 +12,7 @@ > * If multiple threads attempt to lock the same byte (or flock the same file) > * only one can be granted the lock, and other must wait their turn. > * The first lock has been "applied" or "granted", the others are "waiting" > - * and are "blocked" by the "applied" lock.. > + * and are "blocked" by the "applied" lock. > * > * Waiting and applied locks are all kept in trees whose properties are: > * > @@ -43,7 +43,7 @@ > * waiting for the lock so it can continue handling as follows: if the > * root of the tree applies, we do so (3). If it doesn't, it must > * conflict with some applied lock. We remove (wake up) all of its children > - * (2), and add it is a new leaf to the tree rooted in the applied > + * (2), and add it as a new leaf to the tree rooted in the applied > * lock (1). We then repeat the process recursively with those > * children. > * > @@ -1327,7 +1327,7 @@ static int posix_lock_inode(struct inode *inode, struct file_lock *request, > * replacing. If new lock(s) need to be inserted all modifications are > * done below this, so it's safe yet to bail out. > */ > - error = -ENOLCK; /* "no luck" */ > + error = -ENOLCK; /* "no lock" */ FWIW, I think that the above is intended as a joke in English. "Lock" and "luck" sound similar, so this is telling you that you just got unlucky in this case and have no locking. > if (right && left == right && !new_fl2) > goto out; > > @@ -2862,7 +2862,7 @@ static int locks_show(struct seq_file *f, void *v) > return 0; > > /* View this crossed linked list as a binary tree, the first member of flc_blocked_requests > - * is the left child of current node, the next silibing in flc_blocked_member is the > + * is the left child of current node, the next sibling in flc_blocked_member is the > * right child, we can alse get the parent of current node from flc_blocker, so this > * question becomes traversal of a binary tree > */ Typically, we don't take cosmetic cleanup patches unless they are accompanied with substantive changes. If you're working in this area on real code changes and want to clean up a comment, then go for it, but otherwise this sort of change tends to make backporting more difficult later. -- Jeff Layton <jlayton@xxxxxxxxxx>
