From: Xiubo Li <xiubli@xxxxxxxxxx>
We should make it clear where the 189 comes from and why, I almost
forgot why we discard the dirhash[2] in ceph, which we discussed it
months ago.
Signed-off-by: Xiubo Li <xiubli@xxxxxxxxxx>
---
Jeff, you can sqush this into prvious commit too.
fs/ceph/crypto.c | 2 +-
fs/ceph/crypto.h | 8 +++++++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/fs/ceph/crypto.c b/fs/ceph/crypto.c
index c125a79019b3..73320edd32c0 100644
--- a/fs/ceph/crypto.c
+++ b/fs/ceph/crypto.c
@@ -142,7 +142,7 @@ int ceph_encode_encrypted_dname(const struct inode *parent, struct qstr *d_name,
/*
* convert cleartext d_name to ciphertext
- * if result is longer than CEPH_NOKEY_NAME_MAX,
+ * if result is longer than CEPH_NOHASH_NAME_MAX,
* sha256 the remaining bytes
*
* See: fscrypt_setup_filename
diff --git a/fs/ceph/crypto.h b/fs/ceph/crypto.h
index 185fb4799a6d..62f0ddd30dee 100644
--- a/fs/ceph/crypto.h
+++ b/fs/ceph/crypto.h
@@ -76,7 +76,13 @@ static inline u32 ceph_fscrypt_auth_len(struct ceph_fscrypt_auth *fa)
* smaller size. If the ciphertext name is longer than the value below, then
* sha256 hash the remaining bytes.
*
- * 189 bytes => 252 bytes base64-encoded, which is <= NAME_MAX (255)
+ * For the fscrypt_nokey_name struct the dirhash[2] member is useless in ceph
+ * so the corresponding struct will be:
+ *
+ * struct fscrypt_ceph_nokey_name {
+ * u8 bytes[157];
+ * u8 sha256[SHA256_DIGEST_SIZE];
+ * }; // 189 bytes => 252 bytes base64-encoded, which is <= NAME_MAX (255)
*
* Note that for long names that end up having their tail portion hashed, we
* must also store the full encrypted name (in the dentry's alternate_name
--
2.27.0
