* [f2fs-dev] [PATCH v3] f2fs: wait for inode record work before clearing ino bitmaps
@ 2026-09-02 9:06 Wenjie Qi
2026-09-02 9:32 ` Chao Yu via Linux-f2fs-devel
2026-09-03 16:10 ` patchwork-bot+f2fs--- via Linux-f2fs-devel
0 siblings, 2 replies; 3+ messages in thread
From: Wenjie Qi @ 2026-09-02 9:06 UTC (permalink / raw)
To: jaegeuk, chao; +Cc: qwjhust, qiwenjie, linux-kernel, linux-f2fs-devel
APPEND/UPDATE inode state recording was moved to the inode eviction
workqueue. These entries were later converted to bitmap values stored in
XArrays, but the workqueue drain was left behind in the list cleanup loop
where it is now a no-op.
During unmount, inode eviction work can therefore remain queued when
f2fs_release_ino_entry() destroys the bitmap XArrays. A delayed worker can
repopulate them before the workqueue is finally destroyed, leaking newly
allocated XArray nodes when the F2FS superblock is freed.
Wait for APPEND/UPDATE inode record work before destroying each bitmap
XArray, restoring the required ordering.
Fixes: 9a9ee7408a1f ("f2fs: reduce memory footprint of ino management")
Signed-off-by: Wenjie Qi <qiwenjie@xiaomi.com>
---
v3:
- Call flush_workqueue() directly, remove the obsolete helper, and retain
a comment explaining the APPEND/UPDATE state-record wait.
fs/f2fs/checkpoint.c | 14 +++-----------
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 4b59f30ef45d5..cf88b463fde51 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -825,15 +825,6 @@ static void __clear_ino_bitmap(struct f2fs_sb_info *sbi, nid_t ino, int type)
spin_unlock(&im->ino_lock);
}
-static void f2fs_wait_for_inode_record(struct f2fs_sb_info *sbi, int mode)
-{
- if (mode != APPEND_INO && mode != UPDATE_INO)
- return;
-
- /* Let's wait for some pending updates for APPEND_INO and UPDATE_INO. */
- flush_workqueue(sbi->evict_wq);
-}
-
static void __f2fs_add_ino_entry(struct f2fs_sb_info *sbi, nid_t ino,
unsigned int devidx, int type)
{
@@ -887,8 +878,6 @@ void f2fs_release_ino_entry(struct f2fs_sb_info *sbi, bool all)
for (i = all ? ORPHAN_INO : FLUSH_INO; i <= FLUSH_INO; i++) {
struct inode_management *im = &sbi->im[i];
- f2fs_wait_for_inode_record(sbi, i);
-
spin_lock(&im->ino_lock);
list_for_each_entry_safe(e, tmp, &im->ino_list, list) {
list_del(&e->list);
@@ -899,6 +888,9 @@ void f2fs_release_ino_entry(struct f2fs_sb_info *sbi, bool all)
spin_unlock(&im->ino_lock);
}
+ /* Wait for pending APPEND/UPDATE inode state updates. */
+ flush_workqueue(sbi->evict_wq);
+
for (i = APPEND_INO; i < MAX_INO_ENTRY; i++) {
struct inode_management *im = &sbi->im[i];
--
2.43.0
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [f2fs-dev] [PATCH v3] f2fs: wait for inode record work before clearing ino bitmaps
2026-09-02 9:06 [f2fs-dev] [PATCH v3] f2fs: wait for inode record work before clearing ino bitmaps Wenjie Qi
@ 2026-09-02 9:32 ` Chao Yu via Linux-f2fs-devel
2026-09-03 16:10 ` patchwork-bot+f2fs--- via Linux-f2fs-devel
1 sibling, 0 replies; 3+ messages in thread
From: Chao Yu via Linux-f2fs-devel @ 2026-09-02 9:32 UTC (permalink / raw)
To: Wenjie Qi, jaegeuk; +Cc: qiwenjie, linux-kernel, linux-f2fs-devel
On 9/2/26 17:06, Wenjie Qi wrote:
> APPEND/UPDATE inode state recording was moved to the inode eviction
> workqueue. These entries were later converted to bitmap values stored in
> XArrays, but the workqueue drain was left behind in the list cleanup loop
> where it is now a no-op.
>
> During unmount, inode eviction work can therefore remain queued when
> f2fs_release_ino_entry() destroys the bitmap XArrays. A delayed worker can
> repopulate them before the workqueue is finally destroyed, leaking newly
> allocated XArray nodes when the F2FS superblock is freed.
>
> Wait for APPEND/UPDATE inode record work before destroying each bitmap
> XArray, restoring the required ordering.
>
> Fixes: 9a9ee7408a1f ("f2fs: reduce memory footprint of ino management")
> Signed-off-by: Wenjie Qi <qiwenjie@xiaomi.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Thanks,
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [f2fs-dev] [PATCH v3] f2fs: wait for inode record work before clearing ino bitmaps
2026-09-02 9:06 [f2fs-dev] [PATCH v3] f2fs: wait for inode record work before clearing ino bitmaps Wenjie Qi
2026-09-02 9:32 ` Chao Yu via Linux-f2fs-devel
@ 2026-09-03 16:10 ` patchwork-bot+f2fs--- via Linux-f2fs-devel
1 sibling, 0 replies; 3+ messages in thread
From: patchwork-bot+f2fs--- via Linux-f2fs-devel @ 2026-09-03 16:10 UTC (permalink / raw)
To: Wenjie Qi; +Cc: jaegeuk, linux-f2fs-devel, qiwenjie, linux-kernel
Hello:
This patch was applied to jaegeuk/f2fs.git (dev)
by Jaegeuk Kim <jaegeuk@kernel.org>:
On Wed, 2 Sep 2026 17:06:11 +0800 you wrote:
> APPEND/UPDATE inode state recording was moved to the inode eviction
> workqueue. These entries were later converted to bitmap values stored in
> XArrays, but the workqueue drain was left behind in the list cleanup loop
> where it is now a no-op.
>
> During unmount, inode eviction work can therefore remain queued when
> f2fs_release_ino_entry() destroys the bitmap XArrays. A delayed worker can
> repopulate them before the workqueue is finally destroyed, leaking newly
> allocated XArray nodes when the F2FS superblock is freed.
>
> [...]
Here is the summary with links:
- [f2fs-dev,v3] f2fs: wait for inode record work before clearing ino bitmaps
https://git.kernel.org/jaegeuk/f2fs/c/56bcda97b38a
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-09-03 16:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-02 9:06 [f2fs-dev] [PATCH v3] f2fs: wait for inode record work before clearing ino bitmaps Wenjie Qi
2026-09-02 9:32 ` Chao Yu via Linux-f2fs-devel
2026-09-03 16:10 ` patchwork-bot+f2fs--- via Linux-f2fs-devel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox