[PATCH] fs: Fix comment typos and grammatical errors

[PATCH] fs: Fix comment typos and grammatical errors

[Li Lingfeng]

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@huawei.com>
---
 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" */
 	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
 	 */
-- 
2.31.1

Re: [PATCH] fs: Fix comment typos and grammatical errors

[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@huawei.com>
> ---
>  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@kernel.org>

Re: [PATCH] fs: Fix comment typos and grammatical errors

[Li Lingfeng]

在 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@huawei.com>
>> ---
>>   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