From: Chao Yu via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: ensure node page reads complete before f2fs_put_super() finishes
Date: Sat, 11 Oct 2025 11:52:34 +0800 [thread overview]
Message-ID: <ac1bcf67-cc5f-4288-a2f3-c4fb6013c38a@kernel.org> (raw)
In-Reply-To: <aOkuA_Ffq2klE5g6@google.com>
On 10/11/25 00:02, Jaegeuk Kim wrote:
> On 10/09, Chao Yu wrote:
>> On 10/6/2025 4:46 PM, Jan Prusakowski via Linux-f2fs-devel wrote:
>>> Xfstests generic/335, generic/336 sometimes crash with the following message:
>>>
>>> F2FS-fs (dm-0): detect filesystem reference count leak during umount, type: 9, count: 1
>>> ------------[ cut here ]------------
>>> kernel BUG at fs/f2fs/super.c:1939!
>>> Oops: invalid opcode: 0000 [#1] SMP NOPTI
>>> CPU: 1 UID: 0 PID: 609351 Comm: umount Tainted: G W 6.17.0-rc5-xfstests-g9dd1835ecda5 #1 PREEMPT(none)
>>> Tainted: [W]=WARN
>>> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
>>> RIP: 0010:f2fs_put_super+0x3b3/0x3c0
>>> Call Trace:
>>> <TASK>
>>> generic_shutdown_super+0x7e/0x190
>>> kill_block_super+0x1a/0x40
>>> kill_f2fs_super+0x9d/0x190
>>> deactivate_locked_super+0x30/0xb0
>>> cleanup_mnt+0xba/0x150
>>> task_work_run+0x5c/0xa0
>>> exit_to_user_mode_loop+0xb7/0xc0
>>> do_syscall_64+0x1ae/0x1c0
>>> entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>> </TASK>
>>> ---[ end trace 0000000000000000 ]---
>>>
>>> It appears that sometimes it is possible that f2fs_put_super() is called before
>>> all node page reads are completed.
>>> Adding a call to f2fs_wait_on_all_pages() for F2FS_RD_NODE fixes the problem.
>>>
>>> Fixes: bf22c3cc8ce7 ("f2fs: fix the panic in do_checkpoint()")
>>>
>>> Signed-off-by: Jan Prusakowski <jprusakowski@google.com>
>>> ---
>>> fs/f2fs/super.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
>>> index 1e0678e37a30..5c94bc42b8a1 100644
>>> --- a/fs/f2fs/super.c
>>> +++ b/fs/f2fs/super.c
>>> @@ -1976,6 +1976,7 @@ static void f2fs_put_super(struct super_block *sb)
>>> f2fs_flush_merged_writes(sbi);
>>> f2fs_wait_on_all_pages(sbi, F2FS_WB_CP_DATA);
>>> + f2fs_wait_on_all_pages(sbi, F2FS_RD_NODE);
>>
>> Jan,
>>
>> At this stage, GC and checkpoint are both stopped, why there is still read
>> IOs on node page? Who is reading node page? Can you please dig more details
>> for this issue?
>
> We don't actually wait for completing read IOs. So, I think it doesn't matter
> the threads are stopped?
Read on node page should be synchronous? so if the threads are stopped, there
should be no node IOs? Oh, Or there is still pending asynchronous readahead IO
on node page after all threads are stopped?
Thanks,
>
>>
>> Thanks,
>>
>>> if (err || f2fs_cp_error(sbi)) {
>>> truncate_inode_pages_final(NODE_MAPPING(sbi));
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2025-10-11 3:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-06 8:46 [f2fs-dev] [PATCH] f2fs: ensure node page reads complete before f2fs_put_super() finishes Jan Prusakowski via Linux-f2fs-devel
2025-10-09 3:33 ` Chao Yu via Linux-f2fs-devel
2025-10-10 16:02 ` Jaegeuk Kim via Linux-f2fs-devel
2025-10-11 3:52 ` Chao Yu via Linux-f2fs-devel [this message]
2025-10-16 17:47 ` Jaegeuk Kim via Linux-f2fs-devel
2025-10-17 9:47 ` Chao Yu via Linux-f2fs-devel
2025-10-28 18:06 ` Jaegeuk Kim via Linux-f2fs-devel
2025-10-29 1:59 ` Chao Yu via Linux-f2fs-devel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ac1bcf67-cc5f-4288-a2f3-c4fb6013c38a@kernel.org \
--to=linux-f2fs-devel@lists.sourceforge.net \
--cc=chao@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).