Re: [PATCH v3] PM: hibernate: call preallocate_image after freeze prepare

[Rafael J. Wysocki]

On Mon, May 18, 2026 at 3:37 PM Matthew Leach
<matthew.leach@xxxxxxxxxxxxx> wrote:
>
> Hi Rafael,
>
> Matthew Leach <matthew.leach@xxxxxxxxxxxxx> writes:
>
> > Hi Rafael,
> >
> > "Rafael J. Wysocki" <rafael@xxxxxxxxxx> writes:
> >
> >> On Fri, Apr 3, 2026 at 9:36 AM Matthew Leach
> >> <matthew.leach@xxxxxxxxxxxxx> wrote:
> >>>
> >
> > [...]
> >
> >> Can you please have a look at
> >>
> >> https://sashiko.dev/#/patchset/20260403-hibernation-fixes-v3-1-31bc9fa3ba2d%40collabora.com
> >
> > [pasting comment in-line here for comment]
> >
> >
> >> Does this relocation introduce a deadlock during memory reclaim?
> >>
> >> hibernate_preallocate_memory() allocates a large amount of memory and
> >> triggers direct reclaim. Direct reclaim needs to write back dirty file
> >> pages and swap out anonymous pages.
> >>
> >> Since freeze_kernel_threads() just ran, threads required for I/O
> >> completion (like kswapd, jbd2 for Ext4, or WQ_FREEZABLE workqueues) are
> >> currently frozen. Will the I/O for page reclaim block indefinitely
> >> waiting on these frozen threads?
> >
> > The existing code already performs a memory reclaim after
> > freeze_kernel_threads(). The old shrink_shmem_memory() called
> > shrink_all_memory() in the same position, after both
> > freeze_kernel_threads() and dpm_prepare(). This isn't a new pattern
> > being introduced by this patch.
> >
> > Nevertheless, the call chain looks like:
> >
> > shrink_all_memory()
> >   -> do_try_to_free_pages()
> >     -> shrink_zones()
> >       -> shrink_node()
> >         -> shrink_folio_list()
> >           -> pageout()
> >
> > pageout() only writes back shmem and anonymous folios to swap; so jdb2
> > and other FS threads being frozen isn't a concern. For the swap write
> > out, the I/O submission path is via submit_bio() which is also
> > synchronous.
> >
> >> Additionally, because the OOM killer is already disabled by
> >> freeze_processes() earlier in the hibernation path, can the reclaim path
> >> get stuck permanently without being able to fall back to killing
> >> processes?
> >
> > There's nothing new here regarding the OOM killer. freeze_processes()
> > disables it in hibernate() prior to calling hibernation_snapshot().
> > Since this patch is entirely contained within hibernation_snapshot()
> > that pattern hasn't changed.
> >
>
> Quick ping on this. Any throughts on the responses, or anything else
> you'd like me to dig into?

Sorry for the delay, let me have a look at this again.