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@xxxxxxxxxxxxxx>
> ---
> 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
>
