linux-kernel - Re: User-space watchdog timers vs suspend-to-idle

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANDhNCqK26S7p0nypKOytgvzKUL8CMMr4-JbN-8PkNc=Em6VYA@mail.gmail.com>
Date: Thu, 10 Jul 2025 15:34:43 -0700
From: John Stultz <jstultz@...gle.com>
To: Ben Hutchings <ben@...adent.org.uk>
Cc: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>, 
	"Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>, 
	Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>, 
	linux-pm@...r.kernel.org, 1107785@...s.debian.org, 
	Tiffany Yang <ynaffit@...gle.com>
Subject: Re: User-space watchdog timers vs suspend-to-idle

On Thu, Jul 10, 2025 at 2:59 PM John Stultz <jstultz@...gle.com> wrote:
> On Thu, Jul 10, 2025 at 12:52 PM Ben Hutchings <ben@...adent.org.uk> wrote:
> > There seems to be a longstanding issue with the combination of user-
> > space watchdog timers (using CLOCK_MONOTONIC) and suspend-to-idle.  This
> > was reported at <https://bugzilla.kernel.org/show_bug.cgi?id=200595> and
> > more recently at <https://bugs.debian.org/1107785>.
> >
> > During suspend-to-idle the system may be woken by interrupts and the
> > CLOCK_MONOTONIC clock may tick while that happens, but no user-space
> > tasks are allowed to run.  So when the system finally exits suspend, a
> > watchdog timer based on CLOCK_MONOTONIC may expire immediately without
> > the task being supervised ever having an opportunity to pet the
> > watchdog.
> >
> > This seems like a hard problem to solve!
>
> So I don't know much about suspend-to-idle, but I'm surprised it's not
> suspending timekeeping! That definitely seems problematic.

Hrm. The docs here seem to call out that timekeeping is supposed to be
suspended in s2idle:
  https://docs.kernel.org/admin-guide/pm/sleep-states.html#suspend-to-idle

Looking at enter_s2idle_proper():
https://elixir.bootlin.com/linux/v6.16-rc5/source/drivers/cpuidle/cpuidle.c#L154

We call tick_freeze():
https://elixir.bootlin.com/linux/v6.16-rc5/source/kernel/time/tick-common.c#L524

Which calls timekeeping_suspend() when the last cpu's tick has been frozen.

So it seems like the problem might be somehow all the cpus maybe
aren't entering s2idle, causing time to keep running?

thanks
-john