[PATCH v4 08/15] fscrypt: rephrase documentation and comments

[Christian Brauner <brauner@kernel.org>]

Now that we moved fscrypt out of struct inode update the comments to not
imply that it's still located in there.

Signed-off-by: Christian Brauner <brauner@kernel.org>
---
 fs/crypto/fscrypt_private.h |  4 ++--
 fs/crypto/keysetup.c        | 31 +++++++++++++++++--------------
 include/linux/fscrypt.h     | 16 +++++++++-------
 3 files changed, 28 insertions(+), 23 deletions(-)

diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h
index c1d92074b65c..691009df5689 100644
--- a/fs/crypto/fscrypt_private.h
+++ b/fs/crypto/fscrypt_private.h
@@ -231,8 +231,8 @@ struct fscrypt_prepared_key {
  * fscrypt_inode_info - the "encryption key" for an inode
  *
  * When an encrypted file's key is made available, an instance of this struct is
- * allocated and stored in ->i_crypt_info.  Once created, it remains until the
- * inode is evicted.
+ * allocated and stored in the inode's fscrypt info.  Once created, it remains
+ * until the inode is evicted.
  */
 struct fscrypt_inode_info {
 
diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c
index 352d0cfda17d..86bf7724dd27 100644
--- a/fs/crypto/keysetup.c
+++ b/fs/crypto/keysetup.c
@@ -639,15 +639,16 @@ fscrypt_setup_encryption_info(struct inode *inode,
 		goto out;
 
 	/*
-	 * For existing inodes, multiple tasks may race to set ->i_crypt_info.
-	 * So use cmpxchg_release().  This pairs with the smp_load_acquire() in
-	 * fscrypt_get_inode_info().  I.e., here we publish ->i_crypt_info with
-	 * a RELEASE barrier so that other tasks can ACQUIRE it.
+	 * For existing inodes, multiple tasks may race to set the inode's
+	 * fscrypt info. So use cmpxchg_release().  This pairs with the
+	 * smp_load_acquire() in fscrypt_get_inode_info().  I.e., here we
+	 * publish the inode's fscrypt info with a RELEASE barrier so that
+	 * other tasks can ACQUIRE it.
 	 */
 	if (fscrypt_set_inode_info(inode, crypt_info)) {
 		/*
-		 * We won the race and set ->i_crypt_info to our crypt_info.
-		 * Now link it into the master key's inode list.
+		 * We won the race and set the inode's fscrypt info to our
+		 * crypt_info. Now link it into the master key's inode list.
 		 */
 		if (mk) {
 			crypt_info->ci_master_key = mk;
@@ -678,14 +679,16 @@ fscrypt_setup_encryption_info(struct inode *inode,
  *		       %false unless the operation being performed is needed in
  *		       order for files (or directories) to be deleted.
  *
- * Set up ->i_crypt_info, if it hasn't already been done.
+ * Set up the inode's fscrypt info, if it hasn't already been done.
  *
- * Note: unless ->i_crypt_info is already set, this isn't %GFP_NOFS-safe.  So
- * generally this shouldn't be called from within a filesystem transaction.
+ * Note: unless the inode's fscrypt info is already set, this isn't
+ * %GFP_NOFS-safe.  So generally this shouldn't be called from within a
+ * filesystem transaction.
  *
- * Return: 0 if ->i_crypt_info was set or was already set, *or* if the
- *	   encryption key is unavailable.  (Use fscrypt_has_encryption_key() to
- *	   distinguish these cases.)  Also can return another -errno code.
+ * Return: 0 if the inode's fscrypt info was set or was already set, *or* if
+ *         the encryption key is unavailable.  (Use
+ *         fscrypt_has_encryption_key() to distinguish these cases.)  Also can
+ *         return another -errno code.
  */
 int fscrypt_get_encryption_info(struct inode *inode, bool allow_unsupported)
 {
@@ -738,9 +741,9 @@ int fscrypt_get_encryption_info(struct inode *inode, bool allow_unsupported)
  *	   ->i_ino doesn't need to be set yet.
  * @encrypt_ret: (output) set to %true if the new inode will be encrypted
  *
- * If the directory is encrypted, set up its ->i_crypt_info in preparation for
+ * If the directory is encrypted, set up its fscrypt info in preparation for
  * encrypting the name of the new file.  Also, if the new inode will be
- * encrypted, set up its ->i_crypt_info and set *encrypt_ret=true.
+ * encrypted, set up its fscrypt info and set *encrypt_ret=true.
  *
  * This isn't %GFP_NOFS-safe, and therefore it should be called before starting
  * any filesystem transaction to create the inode.  For this reason, ->i_ino
diff --git a/include/linux/fscrypt.h b/include/linux/fscrypt.h
index a62879456873..9a333fd6fe7a 100644
--- a/include/linux/fscrypt.h
+++ b/include/linux/fscrypt.h
@@ -209,10 +209,11 @@ static inline bool fscrypt_set_inode_info(struct inode *inode,
 					  struct fscrypt_inode_info *crypt_info)
 {
 	/*
-	 * For existing inodes, multiple tasks may race to set ->i_crypt_info.
-	 * So use cmpxchg_release().  This pairs with the smp_load_acquire() in
-	 * fscrypt_get_inode_info().  I.e., here we publish ->i_crypt_info with
-	 * a RELEASE barrier so that other tasks can ACQUIRE it.
+	 * For existing inodes, multiple tasks may race to set up the inode's
+	 * fscrypt info. So use cmpxchg_release().  This pairs with the
+	 * smp_load_acquire() in fscrypt_get_inode_info().  I.e., here we
+	 * publish the inode's fscrypt info with a RELEASE barrier so that
+	 * other tasks can ACQUIRE it.
 	 */
 	return cmpxchg_release(fscrypt_addr(inode), NULL, crypt_info) == NULL;
 }
@@ -230,9 +231,10 @@ fscrypt_get_inode_info(const struct inode *inode)
 {
 	/*
 	 * Pairs with the cmpxchg_release() in fscrypt_setup_encryption_info().
-	 * I.e., another task may publish ->i_crypt_info concurrently, executing
-	 * a RELEASE barrier.  We need to use smp_load_acquire() here to safely
-	 * ACQUIRE the memory the other task published.
+	 * I.e., another task may publish the inode's fscrypt info
+	 * concurrently, executing a RELEASE barrier.  We need to use
+	 * smp_load_acquire() here to safely ACQUIRE the memory the other task
+	 * published.
 	 */
 	VFS_WARN_ON_ONCE(!inode->i_sb->s_cop);
 	VFS_WARN_ON_ONCE(!inode->i_sb->s_cop->inode_info_offs);

-- 
2.47.2