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] [day] [month] [year] [list]

Message-ID: <CANDhNCr+7=1W9Oiq3AupXRVasU8FgLorzOnf3_RhYp-WK4qbyg@mail.gmail.com>
Date: Fri, 11 Jul 2025 19:19:12 -0700
From: John Stultz <jstultz@...gle.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Ben Hutchings <ben@...adent.org.uk>, Ingo Molnar <mingo@...hat.com>, 
	Peter Zijlstra <peterz@...radead.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 Fri, Jul 11, 2025 at 1:55 AM Rafael J. Wysocki <rafael@...nel.org> wrote:
> On Fri, Jul 11, 2025 at 12:34 AM John Stultz <jstultz@...gle.com> wrote:
> > 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.
> > >
> > > 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?
>
> Well, there is a suspend-to-idle path in which timekeeping is not suspended.
>
> It is the one in which cpuidle_enter_s2idle() returns 0 (or less)
> causing cpuidle_idle_call() to fall back to call_cpuidle() after
> selecting the deepest available idle state.
>
> This happens when the cpuidle driver in use doesn't implement
> ->enter_s2idle() callbacks for any of its states and the most
> straightforward remedy is to implement those callbacks in the given
> cpuidle driver (they must guarantee that interrupts will not be
> enabled, however).

It seems like in this case maybe would it be better to abort the
suspend if the hardware doesn't really support it?

> There are also cases in which suspending timekeeping is delayed for
> various reasons.  For instance, on some systems, if the temperature is
> too high, the platform will refuse to enter its deepest power state
> (ask platform designers which they thought that this would be a good
> idea), so the kernel waits for the temperature to drop before it
> attempts to go for proper suspend-to-idle.

Hrm. Practically how long would this thermal delay for s2idle be?

> Moreover, if there are wakeup events while suspended that do not cause
> the system to resume (you may regard them as "spurious"), timekeeping
> is resumed and suspended again every time this happens.

Ok,  I'd expect it to be resumed and suspended (though I'm wondering
if that should be rethought)

> So in general time may keep running at least somewhat in the
> suspend-to-idle flow, but this also happens during any system
> suspend-resume flow (timekeeping is only suspended after all devices
> have been suspended and it takes time to suspend them all and
> analogously for resume).

Yeah, for small amounts of time, I do expect that the suspend time
will be slightly shorter than the time that applications are frozen -
obviously to your point about the suprious irq case, that delta might
grow with suspend time, but I'm hoping we're still dealing with
relatively small amounts that won't confuse applications.

But from the bug report it sounds like timekeeping is just never
getting suspended at all, which is unexpected.

thanks
-john