在 2025/4/19 20:39, Jeff Layton 写道:
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.
Hi Jeff,
Thank you for the feedback! I appreciate you taking the time to clarify
the policy around cosmetic changes. I wasn't fully aware of the
backporting implications, and I'll certainly keep this in mind for future
contributions. If I work on substantive changes in this area later, I'll
revisit the cleanup alongside those modifications.
Thanks again for the guidance!
Best regards,
Lingfeng
