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

On Thu, Aug 13, 2026 at 11:30 PM Christoph Hellwig <[email protected]> wrote:
>
> On Mon, Aug 10, 2026 at 09:53:14AM -0700, Daeho Jeong wrote:
> > On Mon, Aug 10, 2026 at 9:34 AM Bart Van Assche <[email protected]> wrote:
> > > This information was shared earlier with Daeho
> > > (https://b.corp.google.com/issues/515470309#comment45): [ ... ]
>
> This does not seem to be information available to the public.
>
> > 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.
>
> This does sound very much like a block layer freezing issue.
>
> > 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.
>
> Thanks, it would be great to fix this properly.

Now, I am considering modifying block/blk-core.c to introduce
freezer-aware error handling in __bio_queue_enter().

The idea is to have __bio_queue_enter() check whether task freezing is
active before it decides to block on mq_freeze_wq.

If the system is in the process of freezing, it would immediately
return an error instead of waiting indefinitely on a frozen pm_wq.

I would greatly appreciate your thoughts on this approach.

Thank you in advance for your time and insights.

>


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