Commit 92cfcd03 authored by Eric Biggers's avatar Eric Biggers

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: a992b20c ("fscrypt: add fscrypt_prepare_new_inode() and fscrypt_set_context()")
Reported-by: default avatarTheodore Y. Ts'o <tytso@mit.edu>
Link: https://lore.kernel.org/r/20201031004556.87862-1-ebiggers@kernel.orgSigned-off-by: default avatarEric Biggers <ebiggers@google.com>
parent 3cea11cd
...@@ -269,9 +269,7 @@ static int fscrypt_setup_iv_ino_lblk_32_key(struct fscrypt_info *ci, ...@@ -269,9 +269,7 @@ static int fscrypt_setup_iv_ino_lblk_32_key(struct fscrypt_info *ci,
* New inodes may not have an inode number assigned yet. * New inodes may not have an inode number assigned yet.
* Hashing their inode number is delayed until later. * Hashing their inode number is delayed until later.
*/ */
if (ci->ci_inode->i_ino == 0) if (ci->ci_inode->i_ino)
WARN_ON(!(ci->ci_inode->i_state & I_CREATING));
else
fscrypt_hash_inode_number(ci, mk); fscrypt_hash_inode_number(ci, mk);
return 0; return 0;
} }
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment