linux-kernel - CLOCK

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: <aKwsNNWsHJg8IKzj@localhost>
Date: Mon, 25 Aug 2025 11:26:12 +0200
From: Miroslav Lichvar <mlichvar@...hat.com>
To: Thomas Gleixner <tglx@...utronix.de>,
	Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: linux-kernel@...r.kernel.org, john.stultz@...aro.org
Subject: CLOCK_AUX stepping

There is an issue with the new system auxiliary clocks. When I make
a larger step of a CLOCK_AUX clock (by clock_settime() or
adjtimex(ADJ_SETOFFSET)), the system slows down significantly to
almost being unusable. This didn't happen with the original
tglx/timers/ptp/driver-auxclock branch, but happens with 6.17-rc1
and later.

Reproducer:
- echo 1 > /sys/kernel/time/aux_clocks/0/aux_clock_enable
- git clone -b staging https://github.com/mlichvar/linuxptp.git
- cd linuxptp && make
- ./phc_ctl CLOCK_AUX0 set

"echo 0 > .../aux_clock_enable" revives the system.

I'm not sure if this isn't just a symptom, but the top functions
reported by perf are:
  87.10%  swapper          [kernel.kallsyms]       [k] queued_spin_lock_slowpath                                    
   6.84%  rcu_exp_gp_kthr  [kernel.kallsyms]       [k] queued_spin_lock_slowpath                                    
   1.90%  rcu_exp_gp_kthr  [kernel.kallsyms]       [k] smp_call_function_single                                     

-- 
Miroslav Lichvar