linux.git/kernel/time/timer_migration.c, branch v7.2-rc1

Merge tag 'timers-core-2026-06-13' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip

2026-06-15T08:09:12+00:00

Pull timer core updates from Thomas Gleixner:
 "Updates for the time/timer core subsystem:

   - Harden the user space controllable hrtimer interfaces further to
     protect against unpriviledged DoS attempts by arming timers in the
     past.

   - Add per-capacity hierarchies to the timer migration code to prevent
     timer migration accross different capacity domains. This code has
     been disabled last minute as there is a pathological problem with
     SoCs which advertise a larger number of capacity domains. The
     problem is under investigation and the code won't be active before
     v7.3, but that turned out to be less intrusive than a full revert
     as it preserves the preparatory steps and allows people to work on
     the final resolution

   - Export time namespace functionality as a recent user can be built
     as a module.

   - Initialize the jiffies clocksource before using it. The recent
     hardening against time moving backward requires that the related
     members of struct clocksource have been initialized, otherwise it
     clamps the readout to 0, which makes time stand sill and causes
     boot delays.

   - Fix a more than twenty year old PID reference count leak in an
     error path of the POSIX CPU timer code.

   - The usual small fixes, improvements and cleanups all over the
     place"

* tag 'timers-core-2026-06-13' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip: (31 commits)
  posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path
  time/jiffies: Register jiffies clocksource before usage
  timers/migration: Temporarily disable per capacity hierarchies
  timers/migration: Turn tmigr_hierarchy level_list into a flexible array
  timers/migration: Deactivate per-capacity hierarchies under nohz_full
  timers/migration: Fix hotplug migrator selection target on asymetric capacity machines
  ntsync: Honour caller's time namespace for absolute MONOTONIC timeouts
  time/namespace: Export init_time_ns and do_timens_ktime_to_host()
  timers/migration: Update stale @online doc to @available
  timers: Fix flseep() typo in kernel-doc comment
  hrtimer: Fix the bogus return type of __hrtimer_start_range_ns()
  hrtimer: Return ktime_t from hrtimer_get_next_event()/hrtimer_next_event_without()
  clocksource: Clean up clocksource_update_freq() functions
  alarmtimer: Remove stale return description from alarm_handle_timer()
  selftests/posix_timers: Use CLOCK_THREAD_CPUTIME_ID for ITIMER_PROF measurements
  scripts/timers: Add timer_migration_tree.py
  timers/migration: Handle capacity in connect tracepoints
  timers/migration: Split per-capacity hierarchies
  timers/migration: Track CPUs in a hierarchy
  timers/migration: Abstract out hierarchy to prepare for CPU capacity awareness
  ...

timers/migration: Temporarily disable per capacity hierarchies

2026-06-09T15:25:54+00:00

Some workloads with different CPU capacities consume more power with
timer migration than before. The recently introduced per capacity
hierarchies were supposed to alleviate this problem. However it appears
to also regress other types of workloads, especially when plenty of
capacities live together in the same machine.

Disable the feature until a reasonable solution is found.

Fixes: 098cbaad8e57 ("timers/migration: Split per-capacity hierarchies")
Reported-by: Christian Loehle 
Signed-off-by: Frederic Weisbecker 
Signed-off-by: Thomas Gleixner 
Link: https://patch.msgid.link/20260609123356.28449-1-frederic@kernel.org
Closes: https://lore.kernel.org/all/3b79338f-6cfc-4722-8062-9103db2c8ad1@arm.com

timers/migration: Fix livelock in tmigr_handle_remote_up()

2026-06-04T12:35:33+00:00

tmigr_handle_remote_cpu() skips timer_expire_remote() when cpu ==
smp_processor_id(), assuming the local softirq path already handled this
CPU's timers.

This assumption is wrong because jiffies can advance after the handling of
the CPU's global timers in run_timer_base(BASE_GLOBAL) and before
tmigr_handle_remote() evaluates the expiry times.

As a consequence a timer which expires after the CPU local timer wheel
advanced and becomes expired in the remote handling is ignored and the
callback is never invoked and removed from the timer wheel.

What's worse is that fetch_next_timer_interrupt_remote() keeps reporting it
as expired, and the event is re-queued with expires == now on each
iteration.  The goto-again loop spins indefinitely.

Fix this by calling timer_expire_remote() unconditionally. That's minimal
overhead for the common case as __run_timer_base() returns immediately if
there is nothing to expire in the local wheel.

[ tglx: Amend change log and add a comment ]

Fixes: 7ee988770326 ("timers: Implement the hierarchical pull model")
Reported-by: Alon Kariv 
Signed-off-by: Amit Matityahu 
Signed-off-by: Thomas Gleixner 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260603170139.33628-1-amitmat@amazon.com

timers/migration: Turn tmigr_hierarchy level_list into a flexible array

2026-06-02T19:34:03+00:00

The level_list array is allocated separately right after the parent
struct. The size of the array is already known.

Move level_list to the struct tail as a flexible array member and fold the
two allocations into a single kzalloc_flex().

Signed-off-by: Rosen Penev 
Signed-off-by: Thomas Gleixner 
Assisted-by: Claude:Opus-4.7
Link: https://patch.msgid.link/20260522231618.41622-1-rosenp@gmail.com

timers/migration: Deactivate per-capacity hierarchies under nohz_full

2026-06-02T19:34:03+00:00

NOHZ_FULL CPUs global timers are guaranteed to be handled by the timekeeper
CPU, which never stops its tick and therefore remains active in the
hierarchy.

But since the introduction of per-capacity hierarchies, this guarantee is
broken because the timekeeper may not belong to the same hierarchy as all
the NOHZ_FULL CPUs.

Fix it with simply turning off capacity awareness when NOHZ_FULL is
running and force a single hierarchy. NOHZ_FULL is not exactly optimized
powerwise anyway.

Fixes: 098cbaad8e57 ("timers/migration: Split per-capacity hierarchies")
Signed-off-by: Frederic Weisbecker 
Signed-off-by: Thomas Gleixner 
Link: https://patch.msgid.link/20260519220926.63437-3-frederic@kernel.org

timers/migration: Fix hotplug migrator selection target on asymetric capacity machines

2026-06-02T19:34:03+00:00

When a top-level migrator is deactivated, either at CPU down hotplug time
or when a CPU is domain isolated, a new migrator is elected among the
available CPUs and woken up to take over the migration duty.

However that election must happen at the scope of a given hierarchy and not
globally, which the introduction of per-capacity hierarchies failed to
handle.

As a result a given hierarchy may end up without migrator to handle global
timers.

Fix it by making sure that the new migrator belongs to the same hierarchy
as the outgoing CPU.

Fixes: 098cbaad8e57 ("timers/migration: Split per-capacity hierarchies")
Signed-off-by: Frederic Weisbecker 
Signed-off-by: Thomas Gleixner 
Link: https://patch.msgid.link/20260519220926.63437-2-frederic@kernel.org

timers/migration: Handle capacity in connect tracepoints

2026-05-06T06:33:07+00:00

This let tracers know to which hierarchy a CPU belongs to.

Signed-off-by: Frederic Weisbecker 
Signed-off-by: Thomas Gleixner 
Link: https://patch.msgid.link/20260423165354.95152-6-frederic@kernel.org

timers/migration: Split per-capacity hierarchies

2026-05-06T06:33:07+00:00

Systems with heterogeneous CPU capacities, such as big.LITTLE, have
reported power issues since the introduction of the new timer migration
code.

Timers migrate from small capacity CPUs to big ones, degrading their
target residency and thus overall power consumption.

Solve this with splitting hierarchies per CPU capacity. For example in
a big.LITTLE machine, split a single hierarchy in two: one for big
capacity CPUs and another one for small capacity CPUs. This way global
timers only migrate across CPUs of the same capacity.

For simplicity purpose, split hierarchies keep the same number of
possible levels as if there were a single hierarchy, even though the
CPUs are distributed between multiple hierarchies. This could be a
problem on NUMA systems with heterogeneous CPU capacities (provided that
ever exists yet) where useless intermediate nodes may be created.
Solving this properly will imply on boot to know in advance how many
capacities are available and the number of CPUs for each of them.

Reported-by: Sehee Jeong 
Suggested-by: Thomas Gleixner 
Signed-off-by: Frederic Weisbecker 
Signed-off-by: Thomas Gleixner 
Link: https://patch.msgid.link/20260423165354.95152-5-frederic@kernel.org

timers/migration: Track CPUs in a hierarchy

2026-05-06T06:33:06+00:00

When a new root is created, the old root is connected to it and
propagates up its own assumed to be active state, since the hotplug
control CPU is itself active and part of the old root.

However with per-capacity hierarchies, this assumption won't be true
anymore because the hotplug control CPU calling the timer migration
prepare callback may not belong to the same hierarchy as the booting
CPU.

To solve this, track the available CPUs per hierarchies so that the
root connection can be offlined to safe CPUs.

Signed-off-by: Frederic Weisbecker 
Signed-off-by: Thomas Gleixner 
Link: https://patch.msgid.link/20260423165354.95152-4-frederic@kernel.org

timers/migration: Abstract out hierarchy to prepare for CPU capacity awareness

2026-05-06T06:33:06+00:00

In order to prepare for separating out CPUs from different capacities in
distinct hierarchies, create a hierarchy structure that group setup
must rely upon.

Signed-off-by: Frederic Weisbecker 
Signed-off-by: Thomas Gleixner 
Link: https://patch.msgid.link/20260423165354.95152-3-frederic@kernel.org