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

[Matthew Leach]

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?

Regards,
-- 
Matt