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

[Rafael J. Wysocki]

On Mon, May 18, 2026 at 3:44 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
>
> 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.

Applied as 7.2 material, thanks!