The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Chao Yu <chao@kernel.org>
To: Zhiguo Niu <niuzhiguo84@gmail.com>
Cc: chao@kernel.org, jaegeuk@kernel.org,
	syzbot+aa5bb5f6860e08a60450@syzkaller.appspotmail.com,
	Qi Han <hanqi@vivo.com>,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH v2] f2fs: fix to skip f2fs_balance_fs() if checkpoint is disabled
Date: Fri, 23 May 2025 10:32:49 +0800	[thread overview]
Message-ID: <6c51b7aa-8caa-4dae-b079-01ea8571599b@kernel.org> (raw)
In-Reply-To: <CAHJ8P3J8cX5+pVkE4TT24zh+wvW06KrpKXT2-7cRx3i8XzBbNw@mail.gmail.com>

On 5/23/25 09:39, Zhiguo Niu wrote:
> Chao Yu via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
> 于2025年5月21日周三 20:02写道:
>>
>> INFO: task syz-executor328:5856 blocked for more than 144 seconds.
>>       Not tainted 6.15.0-rc6-syzkaller-00208-g3c21441eeffc #0
>> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> task:syz-executor328 state:D stack:24392 pid:5856  tgid:5832  ppid:5826   task_flags:0x400040 flags:0x00004006
>> Call Trace:
>>  <TASK>
>>  context_switch kernel/sched/core.c:5382 [inline]
>>  __schedule+0x168f/0x4c70 kernel/sched/core.c:6767
>>  __schedule_loop kernel/sched/core.c:6845 [inline]
>>  schedule+0x165/0x360 kernel/sched/core.c:6860
>>  io_schedule+0x81/0xe0 kernel/sched/core.c:7742
>>  f2fs_balance_fs+0x4b4/0x780 fs/f2fs/segment.c:444
>>  f2fs_map_blocks+0x3af1/0x43b0 fs/f2fs/data.c:1791
>>  f2fs_expand_inode_data+0x653/0xaf0 fs/f2fs/file.c:1872
>>  f2fs_fallocate+0x4f5/0x990 fs/f2fs/file.c:1975
>>  vfs_fallocate+0x6a0/0x830 fs/open.c:338
>>  ioctl_preallocate fs/ioctl.c:290 [inline]
>>  file_ioctl fs/ioctl.c:-1 [inline]
>>  do_vfs_ioctl+0x1b8f/0x1eb0 fs/ioctl.c:885
>>  __do_sys_ioctl fs/ioctl.c:904 [inline]
>>  __se_sys_ioctl+0x82/0x170 fs/ioctl.c:892
>>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>>  do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94
>>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>>
>> The root cause is after commit 84b5bb8bf0f6 ("f2fs: modify
>> f2fs_is_checkpoint_ready logic to allow more data to be written with the
>> CP disable"), we will get chance to allow f2fs_is_checkpoint_ready() to
>> return true once below conditions are all true:
>> 1. checkpoint is disabled
>> 2. there are not enough free segments
>> 3. there are enough free blocks
>>
>> Then it will cause f2fs_balance_fs() to trigger foreground GC.
>>
>> void f2fs_balance_fs(struct f2fs_sb_info *sbi, bool need)
>> ...
>>         if (!f2fs_is_checkpoint_ready(sbi))
>>                 return;
>>
>> And it mounts f2fs image w/ gc_merge,checkpoint=disable, so below deadloop
>> will happen:
>>
>> - f2fs_do_shutdown              - vfs_fallocate                         - gc_thread_func
>>                                  - file_start_write
>>                                   - __sb_start_write(SB_FREEZE_WRITE)
>>                                  - f2fs_fallocate
>>                                   - f2fs_expand_inode_data
>>                                    - f2fs_map_blocks
>>                                     - f2fs_balance_fs
>>                                      - prepare_to_wait
>>                                      - wake_up(gc_wait_queue_head)
>>                                      - io_schedule
>>  - bdev_freeze
>>   - freeze_super
>>    - sb->s_writers.frozen = SB_FREEZE_WRITE;
>>    - sb_wait_write(sb, SB_FREEZE_WRITE);
>>                                                                          - if (sbi->sb->s_writers.frozen >= SB_FREEZE_WRITE) continue;
>>                                                                          : cause deadloop
>>
>> This patch fix to add check condition in f2fs_balance_fs(), so that if
>> checkpoint is disabled, we will just skip trigger foreground GC to
>> avoid above deadloop issue.
>>
>> Reported-by: syzbot+aa5bb5f6860e08a60450@syzkaller.appspotmail.com
>> Closes: https://lore.kernel.org/linux-f2fs-devel/682d743a.a00a0220.29bc26.0289.GAE@google.com
>> Fixes: 84b5bb8bf0f6 ("f2fs: modify f2fs_is_checkpoint_ready logic to allow more data to be written with the CP disable")
>> Cc: Qi Han <hanqi@vivo.com>
>> Signed-off-by: Chao Yu <chao@kernel.org>
>> ---
>> v2:
>> - add missing Closes line
>> - fix to use git commit description style
>>
>>  fs/f2fs/segment.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>> index 5ff0111ed974..19b716fda72a 100644
>> --- a/fs/f2fs/segment.c
>> +++ b/fs/f2fs/segment.c
>> @@ -433,6 +433,8 @@ void f2fs_balance_fs(struct f2fs_sb_info *sbi, bool need)
>>         if (need && excess_cached_nats(sbi))
>>                 f2fs_balance_fs_bg(sbi, false);
>>
>> +       if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED)))
>> +               return;
>>         if (!f2fs_is_checkpoint_ready(sbi))
>>                 return;
> Hi Chao,
> When I read this patch, I feel that it is somewhat redundant with the
> following checking about SBI_CP_DISABLED in f2fs_is_checkpoint_ready.
> Can we reorganize these checks for the f2fs_balance_fs case?

Zhiguo,

Oh, I agreed. I think we can just use is_sbi_flag_set(sbi, SBI_CP_DISABLED)
instead of f2fs_is_checkpoint_ready() here, let me revise it in v3.

-       if (!f2fs_is_checkpoint_ready(sbi))
+       if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED)))

Thanks,

> This will make the code easier to read and understand.
> thanks!
>>
>> --
>> 2.49.0
>>
>>
>>
>> _______________________________________________
>> Linux-f2fs-devel mailing list
>> Linux-f2fs-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel


      reply	other threads:[~2025-05-23  2:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-21 11:56 [PATCH v2] f2fs: fix to skip f2fs_balance_fs() if checkpoint is disabled Chao Yu
2025-05-23  1:39 ` [f2fs-dev] " Zhiguo Niu
2025-05-23  2:32   ` Chao Yu [this message]

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=6c51b7aa-8caa-4dae-b079-01ea8571599b@kernel.org \
    --to=chao@kernel.org \
    --cc=hanqi@vivo.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=niuzhiguo84@gmail.com \
    --cc=syzbot+aa5bb5f6860e08a60450@syzkaller.appspotmail.com \
    /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