Instead of checking I_FREEING, simply check the i_count reference to see if this inode is going away. Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx> --- fs/ext4/inode.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 7674c1f614b1..3950e19cf862 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -199,8 +199,8 @@ void ext4_evict_inode(struct inode *inode) * For inodes with journalled data, transaction commit could have * dirtied the inode. And for inodes with dioread_nolock, unwritten * extents converting worker could merge extents and also have dirtied - * the inode. Flush worker is ignoring it because of I_FREEING flag but - * we still need to remove the inode from the writeback lists. + * the inode. Flush worker is ignoring it because the of the 0 i_count + * but we still need to remove the inode from the writeback lists. */ if (!list_empty_careful(&inode->i_io_list)) inode_io_list_del(inode); @@ -4581,7 +4581,7 @@ int ext4_truncate(struct inode *inode) * or it's a completely new inode. In those cases we might not * have i_rwsem locked because it's not necessary. */ - if (!(inode->i_state & (I_NEW|I_FREEING))) + if (!(inode->i_state & I_NEW) && refcount_read(&inode->i_count) > 0) WARN_ON(!inode_is_locked(inode)); trace_ext4_truncate_enter(inode); -- 2.49.0
