| Message ID | 20201031004556.87862-1-ebiggers@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | fscrypt: remove reachable WARN in fscrypt_setup_iv_ino_lblk_32_key() | expand |
On Fri, Oct 30, 2020 at 05:45:56PM -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@google.com> > > 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: a992b20cd4ee ("fscrypt: add fscrypt_prepare_new_inode() and fscrypt_set_context()") > Reported-by: Theodore Y. Ts'o <tytso@mit.edu> > Signed-off-by: Eric Biggers <ebiggers@google.com> Applied to fscrypt.git#for-stable for 5.10. - Eric
diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index d3c3e5d9b41f7..d595abb8ef90d 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -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. * Hashing their inode number is delayed until later. */ - if (ci->ci_inode->i_ino == 0) - WARN_ON(!(ci->ci_inode->i_state & I_CREATING)); - else + if (ci->ci_inode->i_ino) fscrypt_hash_inode_number(ci, mk); return 0; }