[RFC PATCH 12/17] fscrypt: notify per-extent infos if master key vanishes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
---
 fs/crypto/keyring.c | 7 +++++++
 1 file changed, 7 insertions(+)

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);
-- 
2.38.1




[Index of Archives]     [linux Cryptography]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite News]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]

  Powered by Linux