| Message ID | 6e98cad3640444193ac886267eca0f0a62ea9db0.1672547582.git.sweettea-kernel@dorminy.me (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | fscrypt: add per-extent encryption keys | expand |
diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c index 846f480da081..0c4e917a5281 100644 --- a/fs/crypto/keyring.c +++ b/fs/crypto/keyring.c @@ -886,6 +886,13 @@ static void evict_dentries_for_decrypted_objects(struct fscrypt_master_key *mk) list_for_each_entry(ci, &mk->mk_active_infos, ci_master_key_link) { inode = ci->ci_inode; + if (!inode) { + spin_unlock(&mk->mk_active_infos_lock); + ci->ci_sb->s_cop->forget_extent_info(ci->ci_info_ptr); + spin_lock(&mk->mk_active_infos_lock); + continue; + } + spin_lock(&inode->i_lock); if (inode->i_state & (I_FREEING | I_WILL_FREE | I_NEW)) { spin_unlock(&inode->i_lock);
When fscrypt_infos can be owned by an extent instead of an inode, a new method of evicting the per-extent info for a key being removed is needed. This change adds removal handling to per-extent infos for master key removal. This seems racy to me and I'd love to find a better way to do this, but I can't think of it. Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me> --- fs/crypto/keyring.c | 7 +++++++ 1 file changed, 7 insertions(+)