Skip to content

Commit 92cfcd0

Browse files
committed
fscrypt: remove reachable WARN in fscrypt_setup_iv_ino_lblk_32_key()
I_CREATING isn't actually set until the inode has been assigned an inode number and inserted into the inode hash table. So the WARN_ON() in fscrypt_setup_iv_ino_lblk_32_key() is wrong, and it can trigger when creating an encrypted file on ext4. Remove it. This was sometimes causing xfstest generic/602 to fail on ext4. I didn't notice it before because due to a separate oversight, new inodes that haven't been assigned an inode number yet don't necessarily have i_ino == 0 as I had thought, so by chance I never saw the test fail. Fixes: a992b20 ("fscrypt: add fscrypt_prepare_new_inode() and fscrypt_set_context()") Reported-by: Theodore Y. Ts'o <tytso@mit.edu> Link: https://lore.kernel.org/r/20201031004556.87862-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com>
1 parent 3cea11c commit 92cfcd0

1 file changed

Lines changed: 1 addition & 3 deletions

File tree

fs/crypto/keysetup.c

Lines changed: 1 addition & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -269,9 +269,7 @@ static int fscrypt_setup_iv_ino_lblk_32_key(struct fscrypt_info *ci,
269269
* New inodes may not have an inode number assigned yet.
270270
* Hashing their inode number is delayed until later.
271271
*/
272-
if (ci->ci_inode->i_ino == 0)
273-
WARN_ON(!(ci->ci_inode->i_state & I_CREATING));
274-
else
272+
if (ci->ci_inode->i_ino)
275273
fscrypt_hash_inode_number(ci, mk);
276274
return 0;
277275
}

0 commit comments

Comments
 (0)