linux-ext4 - Re: [PATCH 27/50] fs: use inode_tryget in evict

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250825-jungautor-aprikosen-9e6622636614@brauner>
Date: Mon, 25 Aug 2025 13:43:57 +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
Subject: Re: [PATCH 27/50] fs: use inode_tryget in evict_inodes

On Thu, Aug 21, 2025 at 04:18:38PM -0400, Josef Bacik wrote:
> Instead of checking I_WILL_FREE|I_FREEING we can simply use
> inode_tryget() to determine if we have a live inode that can be evicted.
> 
> Signed-off-by: Josef Bacik <josef@...icpanda.com>
> ---
>  fs/inode.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/inode.c b/fs/inode.c
> index a14b3a54c4b5..4e1eeb0c3889 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -983,12 +983,16 @@ void evict_inodes(struct super_block *sb)
>  	spin_lock(&sb->s_inode_list_lock);
>  	list_for_each_entry(inode, &sb->s_inodes, i_sb_list) {
>  		spin_lock(&inode->i_lock);
> -		if (inode->i_state & (I_NEW | I_FREEING | I_WILL_FREE)) {
> +		if (inode->i_state & I_NEW) {
> +			spin_unlock(&inode->i_lock);
> +			continue;
> +		}
> +
> +		if (!inode_tryget(inode)) {

So it reads like if we fail to take a reference count on @inode then
someone else is already evicting it. I get that.

But what's confusing to me is that the __iget() call you're removing
was an increment from zero earlier in your series because evict_inodes()
was only callable on inodes that had a zero i_count.

Oh, ok, I forgot, you mandate that for an inode to be on an LRU they
must now hold an i_count reference not just an i_obj_count reference.

So in the prior scheme i_count was zero and wouldn't go back up from
zero. In your scheme is i_count guaranteed to be one and after you've
grabbed another reference and it's gone up to 2 is that the max it can
reach or is it possible that i_count can be grabbed by others somehow?

>  			spin_unlock(&inode->i_lock);
>  			continue;
>  		}
>  
> -		__iget(inode);
>  		inode_lru_list_del(inode);
>  		list_add(&inode->i_lru, &dispose);
>  		spin_unlock(&inode->i_lock);
> -- 
> 2.49.0
>