[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250828-risse-negieren-f9a3d1526782@brauner>
Date: Thu, 28 Aug 2025 14:25:21 +0200
From: Christian Brauner <brauner@...nel.org>
To: Josef Bacik <josef@...icpanda.com>
Cc: linux-fsdevel@...r.kernel.org, linux-btrfs@...r.kernel.org,
kernel-team@...com, linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org,
viro@...iv.linux.org.uk, amir73il@...il.com
Subject: Re: [PATCH v2 30/54] fs: change evict_dentries_for_decrypted_inodes
to use refcount
On Tue, Aug 26, 2025 at 11:39:30AM -0400, Josef Bacik wrote:
> Instead of checking for I_WILL_FREE|I_FREEING simply use the refcount to
> make sure we have a live inode.
>
> Signed-off-by: Josef Bacik <josef@...icpanda.com>
> ---
I have no idea how the lifetime of such decrypted inodes are managed.
I suppose they don't carry a separate reference but are still somehow
safe to be accessed based on the mk_decrypted_inodes list. In any case
something must hold an i_obj_count if we want to use igrab() since I
don't see any relevant rcu protection here.
> fs/crypto/keyring.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c
> index 7557f6a88b8f..969db498149a 100644
> --- a/fs/crypto/keyring.c
> +++ b/fs/crypto/keyring.c
> @@ -956,13 +956,16 @@ static void evict_dentries_for_decrypted_inodes(struct fscrypt_master_key *mk)
>
> list_for_each_entry(ci, &mk->mk_decrypted_inodes, ci_master_key_link) {
> inode = ci->ci_inode;
> +
> spin_lock(&inode->i_lock);
> - if (inode->i_state & (I_FREEING | I_WILL_FREE | I_NEW)) {
> + if (inode->i_state & I_NEW) {
> spin_unlock(&inode->i_lock);
> continue;
> }
> - __iget(inode);
> spin_unlock(&inode->i_lock);
> +
> + if (!igrab(inode))
> + continue;
> spin_unlock(&mk->mk_decrypted_inodes_lock);
>
> shrink_dcache_inode(inode);
> --
> 2.49.0
>
Powered by blists - more mailing lists