From: Chao Yu <chao@kernel.org>
To: Daeho Jeong <daeho43@gmail.com>
Cc: chao@kernel.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net, kernel-team@android.com,
Daeho Jeong <daehojeong@google.com>
Subject: Re: [f2fs-dev] [PATCH] f2fs: quiesce background threads during system suspend using PM notifier
Date: Wed, 5 Aug 2026 09:51:03 +0800 [thread overview]
Message-ID: <a5139ae2-79fa-497f-8c7e-624703df8428@kernel.org> (raw)
In-Reply-To: <CACOAw_y_SnSqcB6D6Yw5z7nkrFFr4aAHU6wj2KW4U2N7TeFMNQ@mail.gmail.com>
On 8/5/26 01:35, Daeho Jeong wrote:
> On Tue, Aug 4, 2026 at 4:24 AM Chao Yu <chao@kernel.org> wrote:
>>
>> On 8/4/26 02:42, Daeho Jeong wrote:
>>> On Mon, Aug 3, 2026 at 2:08 AM Chao Yu <chao@kernel.org> wrote:
>>>>
>>>> On 7/30/26 03:23, Daeho Jeong wrote:
>>>>> From: Daeho Jeong <daehojeong@google.com>
>>>>>
>>>>> During system suspend, a race condition can cause f2fs_gc and f2fs_discard
>>>>> threads to call submit_bio() while the underlying block device (e.g., UFS)
>>>>> is in Runtime PM suspend. Because Runtime PM worker threads are already
>>>>> frozen during task freezing, the threads become trapped in
>>>>> __bio_queue_enter() waiting on mq_freeze_wq, leading to a PM freezer
>>>>> timeout.
>>>>>
>>>>> To prevent this deadlock, register a PM notifier to set SBI_IS_SUSPENDING
>>>>> during PM_SUSPEND_PREPARE. Background GC and discard threads check this
>>>>
>>>> Should we cover issue_flush_thread and issue_checkpoint_thread as well in
>>>> where we will submit bio?
>>>
>>> Unlike GC and discard, which are background optimization tasks and can
>>> be safely paused, other operations like checkpoint are critical for
>>> data consistency.
>>> It is better not to interrupt them in the middle of their progress. If
>>> they are running and take too long, it is safer to just let the system
>>> suspend temporarily fail rather than forcibly breaking their
>>> operations.
>>
>> So why foreground thread like ckpt thread or flush thread won't suffer the
>> same issue like gc or discard thread? because foreground thread will prevent
>> UFS from running into suspend state? I may missed something here. :)
>>
>
> Foreground threads (ckpt/flush) issue I/O on-demand for dirty data sync.
> If suspend aborts due to active I/O, it is legitimate and expected
> behavior rather than an issue, as it is a necessary filesystem
> operation under a non-idle workload.
Okay, so if ckpt/flush are active, that means there are userspace applications are
waiting for checkpoint/flush completion, so freeze_processes() form system suspend
still didn't completion, and it won't enter phase 2 (device suspend & freezing pm_wq).
Let me know if I understand it correctly.
> In contrast, f2fs_gc and f2fs_discard are autonomous background
> threads waking up even on an idle system with UFS in Runtime PM
> suspend, which is the main cause of UFS deadlock when entering the
> suspend.
> With ZUFS, GC runs much more frequently, causing frequent suspend aborts.
>
>>>
>>>>
>>>>> flag and immediately stop issuing new bios, allowing them to enter a
>>>>> freezable sleep state cleanly before process freezing begins.
>>>>>
>>>>> Signed-off-by: Daeho Jeong <daehojeong@google.com>
>>>>> ---
>>>>> fs/f2fs/f2fs.h | 3 +++
>>>>> fs/f2fs/gc.c | 13 ++++++++-----
>>>>> fs/f2fs/segment.c | 13 +++++++++----
>>>>> fs/f2fs/super.c | 25 +++++++++++++++++++++++++
>>>>> 4 files changed, 45 insertions(+), 9 deletions(-)
>>>>>
>>>>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>>>>> index f24e30bb5c3d..c46bf4df9412 100644
>>>>> --- a/fs/f2fs/f2fs.h
>>>>> +++ b/fs/f2fs/f2fs.h
>>>>> @@ -25,6 +25,7 @@
>>>>> #include <linux/quotaops.h>
>>>>> #include <linux/part_stat.h>
>>>>> #include <linux/rw_hint.h>
>>>>> +#include <linux/suspend.h>
>>>>>
>>>>> #include <linux/fscrypt.h>
>>>>> #include <linux/fsverity.h>
>>>>> @@ -1494,6 +1495,7 @@ enum {
>>>>> SBI_IS_FREEZING, /* freezefs is in process */
>>>>> SBI_IS_WRITABLE, /* remove ro mountoption transiently */
>>>>> SBI_ENABLE_CHECKPOINT, /* indicate it's during f2fs_enable_checkpoint() */
>>>>> + SBI_IS_SUSPENDING, /* system suspend is in progress */
>>>>> MAX_SBI_FLAG,
>>>>> };
>>>>>
>>>>> @@ -1757,6 +1759,7 @@ struct f2fs_sb_info {
>>>>> struct f2fs_rwsem sb_lock; /* lock for raw super block */
>>>>> int valid_super_block; /* valid super block no */
>>>>> unsigned long s_flag; /* flags for sbi */
>>>>> + struct notifier_block pm_nb; /* for PM notifier */
>>>>> struct mutex writepages; /* mutex for writepages() */
>>>>>
>>>>> #ifdef CONFIG_BLK_DEV_ZONED
>>>>> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
>>>>> index 93bcb35a5b5d..86b2b29402a5 100644
>>>>> --- a/fs/f2fs/gc.c
>>>>> +++ b/fs/f2fs/gc.c
>>>>> @@ -71,7 +71,8 @@ static int gc_thread_func(void *data)
>>>>> if (kthread_should_stop())
>>>>> break;
>>>>>
>>>>> - if (sbi->sb->s_writers.frozen >= SB_FREEZE_WRITE) {
>>>>> + if (sbi->sb->s_writers.frozen >= SB_FREEZE_WRITE ||
>>>>> + is_sbi_flag_set(sbi, SBI_IS_SUSPENDING)) {
>>>>> increase_sleep_time(gc_th, &wait_ms);
>>>>> stat_other_skip_bggc_count(sbi);
>>>>> continue;
>>>>> @@ -1064,8 +1065,9 @@ static int gc_node_segment(struct f2fs_sb_info *sbi,
>>>>> struct node_info ni;
>>>>> int err;
>>>>>
>>>>> - /* stop BG_GC if there is not enough free sections. */
>>>>> - if (gc_type == BG_GC && has_not_enough_free_secs(sbi, 0, 0))
>>>>> + /* stop BG_GC if there is not enough free sections or suspending. */
>>>>> + if (gc_type == BG_GC && (has_not_enough_free_secs(sbi, 0, 0) ||
>>>>> + is_sbi_flag_set(sbi, SBI_IS_SUSPENDING)))
>>>>> return submitted;
>>>>>
>>>>> if (check_valid_map(sbi, segno, off) == 0)
>>>>> @@ -1611,7 +1613,8 @@ static int gc_data_segment(struct f2fs_sb_info *sbi, struct f2fs_summary *sum,
>>>>> * Or, stop GC if the segment becomes fully valid caused by
>>>>> * race condition along with SSR block allocation.
>>>>> */
>>>>> - if ((gc_type == BG_GC && has_not_enough_free_secs(sbi, 0, 0)) ||
>>>>> + if ((gc_type == BG_GC && (has_not_enough_free_secs(sbi, 0, 0) ||
>>>>> + is_sbi_flag_set(sbi, SBI_IS_SUSPENDING))) ||
>>>>> (!force_migrate && get_valid_blocks(sbi, segno, true) ==
>>>>> CAP_BLKS_PER_SEC(sbi)))
>>>>> return submitted;
>>>>> @@ -2015,7 +2018,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, struct f2fs_gc_control *gc_control)
>>>>> goto stop;
>>>>> }
>>>>> retry:
>>>>> - if (unlikely(freezing(current))) {
>>>>
>>>> Shouldn't we keep original freezing logic? in case filesystem are frozen
>>>> when low device snapshot is triggered?
>>>
>>> Since the runtime PM suspend/resume workers are only frozen during
>>> system-wide PM transitions (suspend/hibernation), the PM notifier
>>> approach with SBI_IS_SUSPENDING sufficiently prevents the deadlock.
>>
>> What I mean is:
>>
>> if (is_sbi_flag_set(sbi, SBI_IS_SUSPENDING) || unlikely(freezing(current))) {
>>
>> otherwise, gc thread or discard thread won't detect freeze state, and will
>> continue to trigger IO in background even there is a system freeze request
>> from device snapshot or cgroup freezing, right?
>>
>
> The hang in system suspend happens because Runtime PM workers (pm_wq)
> are frozen, so UFS cannot be resumed from submit_bio().
> During cgroup freeze or snapshot, I believe pm_wq is alive, so UFS
> resumes in a few ms and I/O finishes without deadlock. Also,
> wait_event_freezable_timeout() will freeze the threads when they
> sleep.
Here, we need to detect the freezing state and stop issuing any new I/O
immediately because non-PM freezing mechanisms (such as dm-snapshot or
cgroup freezer) require the underlying filesystem/device to reach a
quiescent (static) state. It's not limited strictly to the PM suspend
state.
>
> If you prefer keeping freezing(current) as a fast path for non-PM
> freezing, I can change it to:
> if (is_sbi_flag_set(sbi, SBI_IS_SUSPENDING) || unlikely(freezing(current)))
> Do you still think it is required? If so, plz, let me know.
Yes, please.
Thanks,
>
> Thanks.
>
>> Thanks,
>>
>>>
>>> Thanks,
>>>
>>>>
>>>>> + if (is_sbi_flag_set(sbi, SBI_IS_SUSPENDING)) {
>>>>> ret = 0;
>>>>> goto stop;
>>>>> }
>>>>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>>>>> index d70dc5ef3de4..e27197953356 100644
>>>>> --- a/fs/f2fs/segment.c
>>>>> +++ b/fs/f2fs/segment.c
>>>>> @@ -1300,7 +1300,8 @@ static int __submit_discard_cmd(struct f2fs_sb_info *sbi,
>>>>> if (dc->state != D_PREP)
>>>>> return 0;
>>>>>
>>>>> - if (is_sbi_flag_set(sbi, SBI_NEED_FSCK))
>>>>> + if (is_sbi_flag_set(sbi, SBI_NEED_FSCK) ||
>>>>> + is_sbi_flag_set(sbi, SBI_IS_SUSPENDING))
>>>>> return 0;
>>>>>
>>>>> #ifdef CONFIG_BLK_DEV_ZONED
>>>>> @@ -1341,6 +1342,9 @@ static int __submit_discard_cmd(struct f2fs_sb_info *sbi,
>>>>> unsigned long flags;
>>>>> bool last = true;
>>>>>
>>>>> + if (is_sbi_flag_set(sbi, SBI_IS_SUSPENDING))
>>>>> + break;
>>>>> +
>>>>> if (len > max_discard_blocks) {
>>>>> len = max_discard_blocks;
>>>>> last = false;
>>>>> @@ -1615,7 +1619,7 @@ static void __issue_discard_cmd_orderly(struct f2fs_sb_info *sbi,
>>>>> if (dc->state != D_PREP)
>>>>> goto next;
>>>>>
>>>>> - if (*issued > 0 && unlikely(freezing(current)))
>>>>
>>>> Ditto,
>>>>
>>>>> + if (is_sbi_flag_set(sbi, SBI_IS_SUSPENDING))
>>>>> break;
>>>>>
>>>>> if (dpolicy->io_aware && !is_idle(sbi, DISCARD_TIME)) {
>>>>> @@ -1688,7 +1692,7 @@ static int __issue_discard_cmd(struct f2fs_sb_info *sbi,
>>>>> list_for_each_entry_safe(dc, tmp, pend_list, list) {
>>>>> f2fs_bug_on(sbi, dc->state != D_PREP);
>>>>>
>>>>> - if (issued > 0 && unlikely(freezing(current))) {
>>>>
>>>> Ditto,
>>>>
>>>> Thanks,
>>>>
>>>>> + if (is_sbi_flag_set(sbi, SBI_IS_SUSPENDING)) {
>>>>> suspended = true;
>>>>> break;
>>>>> }
>>>>> @@ -1955,7 +1959,8 @@ static int issue_discard_thread(void *data)
>>>>> continue;
>>>>> if (kthread_should_stop())
>>>>> return 0;
>>>>> - if (is_sbi_flag_set(sbi, SBI_NEED_FSCK) ||
>>>>> + if (is_sbi_flag_set(sbi, SBI_IS_SUSPENDING) ||
>>>>> + is_sbi_flag_set(sbi, SBI_NEED_FSCK) ||
>>>>> !atomic_read(&dcc->discard_cmd_cnt)) {
>>>>> wait_ms = dpolicy.max_interval;
>>>>> continue;
>>>>> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
>>>>> index d5dc83e613e2..536f3ffe5354 100644
>>>>> --- a/fs/f2fs/super.c
>>>>> +++ b/fs/f2fs/super.c
>>>>> @@ -1979,6 +1979,26 @@ static void destroy_device_list(struct f2fs_sb_info *sbi)
>>>>> kvfree(sbi->devs);
>>>>> }
>>>>>
>>>>> +static int f2fs_pm_notifier(struct notifier_block *nb,
>>>>> + unsigned long action, void *ptr)
>>>>> +{
>>>>> + struct f2fs_sb_info *sbi = container_of(nb, struct f2fs_sb_info, pm_nb);
>>>>> +
>>>>> + switch (action) {
>>>>> + case PM_HIBERNATION_PREPARE:
>>>>> + case PM_SUSPEND_PREPARE:
>>>>> + case PM_RESTORE_PREPARE:
>>>>> + set_sbi_flag(sbi, SBI_IS_SUSPENDING);
>>>>> + break;
>>>>> + case PM_POST_SUSPEND:
>>>>> + case PM_POST_HIBERNATION:
>>>>> + case PM_POST_RESTORE:
>>>>> + clear_sbi_flag(sbi, SBI_IS_SUSPENDING);
>>>>> + break;
>>>>> + }
>>>>> + return NOTIFY_OK;
>>>>> +}
>>>>> +
>>>>> static void f2fs_put_super(struct super_block *sb)
>>>>> {
>>>>> struct f2fs_sb_info *sbi = F2FS_SB(sb);
>>>>> @@ -1986,6 +2006,8 @@ static void f2fs_put_super(struct super_block *sb)
>>>>> int err = 0;
>>>>> bool done;
>>>>>
>>>>> + unregister_pm_notifier(&sbi->pm_nb);
>>>>> +
>>>>> /* unregister procfs/sysfs entries in advance to avoid race case */
>>>>> f2fs_unregister_sysfs(sbi);
>>>>>
>>>>> @@ -5472,6 +5494,9 @@ static int f2fs_fill_super(struct super_block *sb, struct fs_context *fc)
>>>>>
>>>>> f2fs_restore_device_alias(sbi);
>>>>>
>>>>> + sbi->pm_nb.notifier_call = f2fs_pm_notifier;
>>>>> + register_pm_notifier(&sbi->pm_nb);
>>>>> +
>>>>> sbi->umount_lock_holder = NULL;
>>>>> return 0;
>>>>>
>>>>
>>
next prev parent reply other threads:[~2026-08-05 1:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 19:23 [PATCH] f2fs: quiesce background threads during system suspend using PM notifier Daeho Jeong
2026-08-03 9:08 ` [f2fs-dev] " Chao Yu
2026-08-03 18:42 ` Daeho Jeong
2026-08-04 11:24 ` Chao Yu
2026-08-04 17:35 ` Daeho Jeong
2026-08-05 1:51 ` Chao Yu [this message]
2026-08-05 16:45 ` Daeho Jeong
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=a5139ae2-79fa-497f-8c7e-624703df8428@kernel.org \
--to=chao@kernel.org \
--cc=daeho43@gmail.com \
--cc=daehojeong@google.com \
--cc=kernel-team@android.com \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--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