Re: [f2fs-dev] [PATCH v2] f2fs: quiesce background threads during system suspend using PM notifier

On Mon, Aug 10, 2026 at 9:34 AM Bart Van Assche <[email protected]> wrote:
>
> On 8/10/26 8:54 AM, Christoph Hellwig wrote:
> > On Thu, Aug 06, 2026 at 10:01:08AM -0700, Daeho Jeong wrote:
> >> From: Daeho Jeong <[email protected]>
> >>
> >> 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.
> >
> > That does sound like a general issue with our block device / threading
> > handling.
>
> Daeho's description above mixes up unrelated topics. A runtime suspended
> UFS device is resumed automatically by the block layer if necessary. The
> issue Daeho is trying to solve is unrelated to runtime suspend according
> to my understanding.
>
> >> To prevent this deadlock, register a PM notifier to set SBI_IS_SUSPENDING
> >> during PM_SUSPEND_PREPARE. Background GC and discard threads check this
> >> flag and immediately stop issuing new bios, allowing them to enter a
> >> freezable sleep state cleanly before process freezing begins.
> >>
> >> In addition, check freezing() as a fast path to stop issuing new I/O
> >> when non-PM freezing (e.g. dm-snapshot or cgroup freezer) is requested.
> >
> > .. which means that we really sould have all the relevant parties
> > invited into figuring out whast is happening here, rather than
> > band-aiding something that looks like a horrible hack inside a
> > file system.
> >
> > Unfortunately I see this a lot with f2fs.  Please reach out to all
> > relevant maintainers for something that does not look strictly local
> > to f2fs.
>
> This information was shared earlier with Daeho
> (https://b.corp.google.com/issues/515470309#comment45): [ ... ]
> Register a Freezable Kernel Thread (Recommended) [ ... ]
> Why this works: During suspend, freezer stops freezable kernel threads
> before devices and block queues enter their PM suspend phases. When the
> queue freezes later, your thread is already safely sleeping in
> try_to_freeze() and will not attempt submit_bio(). [ ... ]

Hi Bart,

To clarify it:

f2fs threads are already freezable: f2fs_gc and f2fs_discard are
already registered with set_freezable() and call try_to_freeze().
However, a race window exists: a thread checks freezing() (false),
calls submit_bio(), and gets trapped inside __bio_queue_enter().
Because it gets blocked before reaching try_to_freeze(), it triggers a
PM freezer timeout.

Hi Christoph,

Point taken. Aside from this f2fs patch, I agree that addressing this
at the block layer or PM subsystem level would be a much cleaner,
system-wide solution.
I’ll give more thought to how we can properly solve this race
condition for the entire system, and I'll loop in the relevant
PM/block maintainers if a viable generic approach emerges.

Thank you,

>
> PS: I'm no longer subscribed to the f2fs-devel mailing list.
>
> Bart.


_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel