Re: [BUG REPORT] potential deadlock in inode evicting under the inode lru traversing context on ext4 and ubifs

[Zhihao Cheng]

在 2024/7/18 11:04, Ryder Wang 写道:
Hi, Ryder
> > Um, I don't see how this can happen.  If the ea_inode is in use,
> > i_count will be greater than zero, and hence the inode will never be
> > go down the rest of the path in inode_lru_inode():
> >
> >          if (atomic_read(&inode->i_count) ||
> >              ...) {
> >                  list_lru_isolate(lru, &inode->i_lru);
> >                  spin_unlock(&inode->i_lock);
> >                  this_cpu_dec(nr_unused);
> >                  return LRU_REMOVED;
> >          }
>
> Yes, in the function inode_lru_inode (in case of clearing cache), there has been such inode->i_state check mechanism to avoid double-removing the inode which is being removed by another process. Unluckily, no such similar inode->i_state check mechanism in the function iput_final (in case of removing file), so double-removing inode can still appear.

I'm a little confused about the process of inode double-removing, can 
you provide a detailed case about how double-revemoving happens? I can't 
find the relationship between inode double-removing and the problem i 
described.
> It looks we need to add some inode->i_state check in iput_final() , if we want to fix this race condition bug.