Re: [PATCH v3 09/16] fscrypt: revamp key removal for extent encryption

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Aug 08, 2023 at 01:08:26PM -0400, Sweet Tea Dorminy wrote:
> @@ -1017,6 +1020,12 @@ static int do_remove_key(struct file *filp, void __user *_uarg, bool all_users)
>  	mk = fscrypt_find_master_key(sb, &arg.key_spec);
>  	if (!mk)
>  		return -ENOKEY;
> +
> +	if (fscrypt_fs_uses_extent_encryption(sb)) {
> +		/* Keep going even if this has an error. */
> +		try_to_lock_encrypted_files(sb, mk);
> +	}

Why is this here?

> @@ -606,6 +615,8 @@ static void put_crypt_info(struct fscrypt_info *ci)
>  
>  	mk = ci->ci_master_key;
>  	if (mk) {
> +		bool any_inodes;
> +
>  		/*
>  		 * Remove this inode from the list of inodes that were unlocked
>  		 * with the master key.  In addition, if we're removing the last
> @@ -614,7 +625,28 @@ static void put_crypt_info(struct fscrypt_info *ci)
>  		 */
>  		spin_lock(&mk->mk_decrypted_inodes_lock);
>  		list_del(&ci->ci_master_key_link);
> +		any_inodes = list_empty(&mk->mk_decrypted_inodes);
>  		spin_unlock(&mk->mk_decrypted_inodes_lock);
> +		if (any_inodes) {
> +			bool soft_deleted;
> +			/* It might be that someone tried to remove this key,
> +			 * but there were still inodes open that could need new
> +			 * extents, which needed to be able to access the key
> +			 * secret. But now this was the last reference. So we
> +			 * can delete the key secret now. (We don't need to
> +			 * check for new inodes on the decrypted_inode list
> +			 * because once ->mk_soft_deleted is set, no new inode
> +			 * can join the list.
> +			 */
> +			down_write(&mk->mk_sem);
> +			soft_deleted = mk->mk_soft_deleted;
> +			if (soft_deleted)
> +				fscrypt_wipe_master_key_secret(&mk->mk_secret);
> +			up_write(&mk->mk_sem);
> +			if (soft_deleted)
> +				fscrypt_put_master_key_activeref(ci->ci_sb, mk);
> +		}
> +

What is all this for?  I'd have thought this would just use the existing
refcounting and no change would be needed here.

- Eric