[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ed4673380176f640f0d33201387999207dc1426a.1755806649.git.josef@toxicpanda.com>
Date: Thu, 21 Aug 2025 16:18:54 -0400
From: Josef Bacik <josef@...icpanda.com>
To: linux-fsdevel@...r.kernel.org,
linux-btrfs@...r.kernel.org,
kernel-team@...com,
linux-ext4@...r.kernel.org,
linux-xfs@...r.kernel.org,
brauner@...nel.org,
viro@...IV.linux.org.uk
Subject: [PATCH 43/50] ext4: remove reference to I_FREEING in inode.c
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@...icpanda.com>
---
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
Powered by blists - more mailing lists