PM: hibernate freeze/image-creation stage has no watchdog-equivalent protection (real 6h12m stall)

Hi,

Real-world report, not a patch -- happy to help test if useful, but wanted to raise this while it's fresh and while the related watchdog work is active.

System: Debian 12.15, kernel 6.1.0-54-amd64 (Debian's packaged LTS -- predates the DPM watchdog extension below, noted explicitly so I'm not overclaiming what I actually reproduced).

On 2026-11-10, an automated maintenance script called systemctl hibernate after a normal, successful run. Kernel log:

  Nov 10 03:40:23 kernel: PM: hibernation: hibernation entry
  <complete silence for 6h12m -- no kernel messages of any kind, confirmed
   via journalctl -k across that whole span>
  Nov 11 09:52:27 kernel: PM: hibernation: Marking nosave pages: ...
  Nov 11 09:52:28 kernel: PM: hibernation: Creating image:
  Nov 11 09:52:28 kernel: PM: hibernation: Need to copy 1573875 pages
  Nov 11 09:52:28 kernel: PM: hibernation: Basic memory bitmaps freed
  Nov 11 09:52:28 kernel: PM: hibernation: hibernation exit

No second "hibernation entry" -- this is one continuous call that took 6h12m to get from entry to its own snapshot-prep steps, then aborted without ever writing an image or powering off. Userspace was frozen for the entire span (a 5-minute heartbeat process went completely silent for the same window), so whatever it was stuck on, it wasn't something a userspace watchdog could have caught -- the watchdog would freeze too.

Two things point at where the kernel's own protection stops:

1. Task-freezing has a real, enforced 20s timeout -- a failure there logs "Freezing of tasks failed after 20.0x seconds". That message never appears, which rules out that specific stage.

2. Device suspend/resume has the DPM watchdog. I checked its current scope directly against commit 3339234 ("PM: sleep: Add DPM watchdog to prepare/late/early/noirq/complete phases", landed 2026-09-25) -- it wraps device_prepare, device_suspend_late, device_suspend_noirq, device_resume_noirq, device_resume_early, device_complete. That's the suspend/resume path. It doesn't appear to touch the hibernate-specific freeze/image-creation callback path (the stage our real stall actually hung in, based on where the log picks back up).

So: a real stall landed in exactly the stage that (as far as I can tell from the commit itself) still has no watchdog-equivalent coverage, even after the recent extension. I don't have a fix to offer -- this isn't a patch submission -- but given 3339234 is recent and the scope question is fresh, wanted to flag the gap with real evidence rather than file it as a cold, unsubstantiated report.

Happy to provide more logs, test a patch, or file this properly via bugzilla.kernel.org instead if that's the better venue for something at this stage (report vs. patch) -- let me know which you'd prefer.

Thanks,
Patrick Boake
[email protected]