lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250419085554.1452319-1-lilingfeng3@huawei.com>
Date: Sat, 19 Apr 2025 16:55:54 +0800
From: Li Lingfeng <lilingfeng3@...wei.com>
To: <viro@...iv.linux.org.uk>, <brauner@...nel.org>, <jack@...e.cz>,
	<chuck.lever@...cle.com>, <jlayton@...nel.org>, <alex.aring@...il.com>,
	<linux-fsdevel@...r.kernel.org>, <linux-kernel@...r.kernel.org>
CC: <yukuai1@...weicloud.com>, <houtao1@...wei.com>, <yi.zhang@...wei.com>,
	<yangerkun@...wei.com>, <lilingfeng@...weicloud.com>,
	<lilingfeng3@...wei.com>
Subject: [PATCH] fs: Fix comment typos and grammatical errors

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@...wei.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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ