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

Message-ID: <3cbd9533b091576a62f597691ced375850d7464a.camel@decadent.org.uk>
Date: Thu, 10 Jul 2025 21:52:30 +0200
From: Ben Hutchings <ben@...adent.org.uk>
To: 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>,  John Stultz <jstultz@...gle.com>, Thomas
 Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>, linux-pm@...r.kernel.org, 
	1107785@...s.debian.org
Subject: User-space watchdog timers vs suspend-to-idle

Hi all,

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!

By definition we cannot allow CLOCK_MONOTONIC to run backward, and I
assume we do not want it to stop while interrupts are being handled. 
But could CLOCK_MONOTONIC be split into a CLOCK_MONOTONIC_KERNEL (may
tick during suspend-to-idle) and CLOCK_MONOTONIC_USER (only ticks while
user tasks can run), with user-space CLOCK_MONOTONIC being the latter? 
(I'm aware that adding yet another clock type would be a rather large
job even if this is possible.)

Until and unless that happens, is it possible to detect that
CLOCK_MONOTONIC advanced during suspend-to-idle by reading e.g.
/proc/schedtat?  If not, could the necessary information be exposed
through one of the pseudo-filesystems?

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)