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

[Patrick Boake <patrick@boake.ca>]

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
patrick@boake.ca