[REGRESSION] /proc/stat idle time exceeds wall clock since v7.2

[Ahmed Shaltout <ahmedshaltout.payment@gmail.com>]

Hello,

Since moving from 7.1.8 to 7.2.5 (openSUSE MicroOS kernel-default), the idle
time reported in /proc/stat exceeds the wall-clock time the CPUs have been up
for. Idle alone accrues ~103% of the ceiling, and user+nice+system+idle+iowait
+irq+softirq+steal sums to ~108% of it.

This breaks the common `100 - rate(idle)` derivation of CPU utilisation, which
goes negative on an idle-but-working machine. node_exporter, and anything built
on it, is affected.

#regzbot introduced: v7.1..v7.2

Reproducer
==========

No tooling needed; /proc/uptime shows it directly, since its second field is
idle time and cannot legitimately exceed uptime x nr_cpus:

  read -r up idle < /proc/uptime && awk -v u="$up" -v i="$idle" -v c="$(nproc)" \
    'BEGIN{printf "idle %.2f%% of ceiling\n", 100*i/(u*c)}'

  7.2.5:  idle 103.10% of ceiling
  7.1.8:  idle  89.13% of ceiling

A 60-second delta over the per-CPU lines of /proc/stat, on 7.2.5, 8 CPUs,
ceiling 480.04 CPU-seconds:

  user      	9.95     	2.07%
  nice    	0.00    	0.00%
  system 	6.56     	1.37%
  idle       	495.44  	103.21%
  iowait   	2.40     	0.50%
  irq          0.00     	0.00%
  softirq   	2.83     	0.59%
  steal    	0.00     	0.00%

  BUSY 	21.74     	4.53%
  IDLE 	495.44   	103.21%
  TOTAL  	517.18   	107.74%   excess 37.14 CPU-seconds

The busy modes are consistent with the machine's actual load; the entire
excess is in the idle column. The same measurement on 7.1.8 gives
478.49 / 480.07 = 0.9967.

/proc/stat and /proc/uptime agree with each other exactly on both kernels
(stat_idle / uptime_idle = 1.0000), so proc_stat(5)'s equality clause holds.
What is violated is wall clock alone. That appears to place the problem in
the counter both files read rather than in the /proc plumbing.

Environment
===========

  AMD EPYC-Rome, KVM guest (Hetzner Cloud), 8 vCPUs
  clocksource: kvm-clock
  CONFIG_HZ=1000, CONFIG_HZ_1000=y
  CONFIG_NO_HZ_COMMON=y, CONFIG_NO_HZ_FULL=y, CONFIG_NO_HZ=y
  CONFIG_VIRT_CPU_ACCOUNTING_GEN=y, CONFIG_VIRT_CPU_ACCOUNTING=y
  CONFIG_SCHED_HRTICK=y
  CONFIG_TICK_CPU_ACCOUNTING, CONFIG_IRQ_TIME_ACCOUNTING and
  CONFIG_PARAVIRT_TIME_ACCOUNTING are all unset
  no nohz_full= on the command line; /sys/devices/system/cpu/nohz_full is empty
  cmdline is otherwise identical between the two kernels (psi=1, selinux=1)

The kernel configuration above is byte-identical between 7.1.8 and 7.2.5 for
every option listed.

Already ruled out
=================

  - Userspace: the raw /proc/stat and /proc/uptime numbers show it; no
    exporter involved.
  - Clocksource: kvm-clock on both.
  - NTP: offset 0, sync_status 1.
  - nohz_full: compiled in but not enabled; the cpumask is empty on both.
  - Possible-vs-online CPU miscount: possible == online == nproc == 8. The
    measurement above uses the per-CPU cpuN lines only, and the aggregate-
    versus-per-CPU deltas were 14, 7 and 18 jiffies.
  - Since-boot accumulation: the figures are deltas over a fresh 60s window.
  - Steal deferral: kcpustat_idle_stop() defers steal subtraction by one
    window by design, but steal is 0.00 here and that deviation is bounded
    and self-cancelling in any case.

Suspected origin
================

This is a distro-kernel comparison, not a mainline bisect -- I have not
bisected and cannot currently do so on these machines, so please treat the
attribution below as a guess rather than a finding.

The only v7.2 change I can find touching this path is the tick/nohz series
merged as timers-nohz-2026-06-13 ("tick/sched: Refactor idle cputime
accounting"). The behaviour matches the version boundary exactly: absent in
7.1.8, present in 7.2.5. I note the series was motivated by idle going
*backwards*, i.e. the opposite direction from what I am seeing, so this may
well be an unrelated interaction.

I also checked whether this might be an intended change in what /proc/stat
promises, and could not find evidence that it is: Documentation/filesystems/
proc.rst is unchanged between v7.1 and v7.2, the series touches no
Documentation/ file, and proc_stat(5) carries no "since Linux 7.2" note. If
the semantics did change deliberately, a pointer to where that is recorded
would be welcome and I will adjust our side instead.

Happy to test patches or gather more data -- these are long-running machines
and the effect is present continuously, so it is easy to measure.

Thanks,
Shaltout,