Re: [PATCH 6.18 0167/1250] PM: hibernate: call preallocate_image() after freeze prepare

Re: [PATCH 6.18 0167/1250] PM: hibernate: call preallocate_image() after freeze prepare

[David Lomas]

Please note, I'm chasing a bug on this laptop using claude, and not
familiar at all with kernel development, so take what it's written
below with a pinch of whatever you prefer. But it seems pretty
convinced it has found the root cause of periodic freezes during
hibernation (whether from sleep on a timer, or direct via 'systemctl
hibernate').

Re: <20260917151556.616977299@linuxfoundation.org>
Upstream commit 783c8109844503bd1c35dab41b6d5fd074a9f131 deadlocks
hibernation entry on my machine (7.2.4, Dell XPS 13 9360, 8 GB, zswap
on) whenever the system has been in use for some hours: the hibernate
call never returns and the laptop sits warm with no image written,
seven times in ten days. Direct `systemctl hibernate` and
suspend-then-hibernate are the same. Never on 7.1.x or 6.18.49, and
never on a fresh boot.

Captured with SysRq (w) after ~8 minutes hung. The hibernating task is
in the direct-reclaim throttle waiting for kswapd, which was frozen 27
ms earlier by freeze_kernel_threads(), which this commit moved ahead
of hibernate_preallocate_memory():

  [ 8404.650787] Freezing remaining freezable tasks completed (elapsed
0.001 seconds)
  [ 8404.677608] PM: hibernation: Preallocating image memory
  (nothing further; SysRq at 8871)

  task:systemd-sleep   state:D pid:36677
   __schedule
   schedule
   throttle_direct_reclaim+0x358/0x3e0
   try_to_free_pages+0xbf/0x220
   __alloc_pages_slowpath.constprop.0+0x531/0x1510
   __alloc_frozen_pages_noprof+0x334/0x370
   alloc_pages_mpol+0xb2/0x160
   alloc_pages_noprof+0x49/0x90
   preallocate_image_memory+0x35/0x9b
   hibernate_preallocate_memory+0x25b/0x390
   hibernation_snapshot+0xc1/0x4e0
   hibernate.cold+0x117/0x4b5
   state_store+0xf2/0x100

  Node 0 Normal free:32044kB boost:119232kB min:172224kB low:185472kB
  high:198720kB ... inactive_anon:1601740kB zspages:362688kB
  377713 pages in swap cache

All four CPUs idle (SysRq l). Free memory is below the pfmemalloc
reserve (two thirds of which is watermark boost), so the GFP_KERNEL
allocations in preallocate_image_memory() go through
throttle_direct_reclaim(), which does wait_event_killable() on
pgdat->pfmemalloc_wait until kswapd raises free pages above the
reserve. kswapd is frozen, so nothing ever wakes it. The wait is
killable, so the hung-task detector does not report it either. With
hung_task_panic, softlockup_panic and hardlockup_panic all set,
nothing fired in eight minutes.

This is the concern Rafael raised on v3 (frozen kswapd); the reply
covered the I/O path but not the pfmemalloc throttle. Reverting the
order, or bypassing the throttle for the hibernation task (PF_KTHREAD
style), would avoid it. Setting vm.watermark_boost_factor=0 shrinks
the window but does not close it.

Full SysRq dump (l/m/w, via efi-pstore) available on request.

#regzbot introduced: 783c8109844503bd1c35dab41b6d5fd074a9f131

David Lomas

Re: [PATCH 6.18 0167/1250] PM: hibernate: call preallocate_image() after freeze prepare

[Sasha Levin]

>   task:systemd-sleep   state:D pid:36677
>    throttle_direct_reclaim+0x358/0x3e0
>    try_to_free_pages+0xbf/0x220
>    preallocate_image_memory+0x35/0x9b
>    hibernate_preallocate_memory+0x25b/0x390
>    hibernation_snapshot+0xc1/0x4e0

Rafael, Matthew: there is no fix or revert in mainline, and 7.2 has the
commit in its base release, so 7.2.y users keep the hang whatever the
stable queues do. Should the ordering go back, or should the hibernation
task bypass the pfmemalloc throttle?

The commit has no Fixes: and no Cc: stable, so nothing is lost by
holding it out of 6.18.y until that is settled.

-- 
Thanks,
Sasha

Re: [PATCH 6.18 0167/1250] PM: hibernate: call preallocate_image() after freeze prepare

[Thorsten Leemhuis]

On 9/20/26 19:50, Sasha Levin wrote:
>>   task:systemd-sleep   state:D pid:36677
>>    throttle_direct_reclaim+0x358/0x3e0
>>    try_to_free_pages+0xbf/0x220
>>    preallocate_image_memory+0x35/0x9b
>>    hibernate_preallocate_memory+0x25b/0x390
>>    hibernation_snapshot+0xc1/0x4e0
> 
> Rafael, Matthew: there is no fix or revert in mainline, and 7.2 has the
> commit in its base release, so 7.2.y users keep the hang whatever the
> stable queues do. Should the ordering go back, or should the hibernation
> task bypass the pfmemalloc throttle?

Not my area of expertise, butm FWIW, Florian Schmaus (now CCed) on
Saturday posted a fix referencing the culprit and from a very brief
looks sounds like it might address David's problem:

PM: hibernate: Freeze kernel threads after image
preallocationhttps://lore.kernel.org/all/20260920-fix-hibernation-v1-1-f9940c2d7d7f@geekplace.eu/#t
David, you might want to take a closer look or even try that patch.

Ciao, Thorsten

#regzbot title: PM: hibernate: deadlock due to waiting for kswapd

Re: [PATCH 6.18 0167/1250] PM: hibernate: call preallocate_image() after freeze prepare

[David Lomas]

> David, you might want to take a closer look or even try that patch.

I'm building 7.2.6 with that patch, and will run it for a few days;
obviously hard to prove a negative, but usually on 7.2 after 2–3 days
of continuous use, a hibernate would hang.

I had one more hang yesterday, captured with SysRq: the same deadlock,
systemd-sleep in throttle_direct_reclaim() under
preallocate_image_memory(), waiting on the frozen kswapd. That one was
with vm.watermark_boost_factor=0.

Re: [PATCH 6.18 0167/1250] PM: hibernate: call preallocate_image() after freeze prepare

[Sasha Levin]

On Sat, Sep 19, 2026 at 02:47:25PM +0100, David Lomas wrote:
> Upstream commit 783c8109844503bd1c35dab41b6d5fd074a9f131 deadlocks
> hibernation entry on my machine (7.2.4, Dell XPS 13 9360, 8 GB, zswap
> on) whenever the system has been in use for some hours: the hibernate
> call never returns and the laptop sits warm with no image written,

Thank you for the report!

> Captured with SysRq (w) after ~8 minutes hung. The hibernating task is
> in the direct-reclaim throttle waiting for kswapd, which was frozen 27
> ms earlier by freeze_kernel_threads(), which this commit moved ahead
> of hibernate_preallocate_memory():

I've dropped the patch from the 6.18 queue. 783c8109 has not appeared in
a released 6.18.y yet (v6.18.52 is the latest), so dropping it from the
queue is enough to keep 6.18.y clear of this.

-- 
Thanks,
Sasha

Re: [PATCH 6.18 0167/1250] PM: hibernate: call preallocate_image() after freeze prepare

[David Lomas]

Same commit, same symptom: my report with the blocked-task backtrace
is at https://lore.kernel.org/all/CALjEBWQo0-Sdimo+aRNKUQvgDGw=jBFCcfwCXaqVdtoPrHLAQA@mail.gmail.com/
(XPS 13 9360, 8 GB, zswap). The hibernating task sits in
throttle_direct_reclaim() waiting for kswapd, which
freeze_kernel_threads() froze just before
hibernate_preallocate_memory() ran.

#regzbot introduced: 783c8109844503bd1c35dab41b6d5fd074a9f131

David

Re: [PATCH 6.18 0167/1250] PM: hibernate: call preallocate_image() after freeze prepare

[Hic Haec Hoc]

On 9 Saturday 19 Sep 2026 at 22:53 David Lomas <david.s.lomas@gmail.com> wrote:
>
> Same commit, same symptom: my report with the blocked-task backtrace
> is at https://lore.kernel.org/all/CALjEBWQo0-Sdimo+aRNKUQvgDGw=jBFCcfwCXaqVdtoPrHLAQA@mail.gmail.com/
> (XPS 13 9360, 8 GB, zswap). The hibernating task sits in
> throttle_direct_reclaim() waiting for kswapd, which
> freeze_kernel_threads() froze just before
> hibernate_preallocate_memory() ran.
>
> #regzbot introduced: 783c8109844503bd1c35dab41b6d5fd074a9f131
>
> David

Hello,

I'm replying to this message because I was not CCed on the later ones.

I can reproduce the issue quite reliably on this machine, and with
Florian Schmaus's patch applied on top of 7.2.5 it survived ten
hibernate/resume cycles under significant memory pressure without
hanging. I can't tell if it could reintroduce the problems that
783c8109844503bd1c35dab41b6d5fd074a9f131 was trying to avoid but at a
minimum it seems to fix this particular deadlock.

Best regards,

H.