linux-kernel - Re: [patch 00/26] timekeeping: Provide support for independent PTP timekeepers

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

Message-ID: <871psrk1x2.ffs@tglx>
Date: Wed, 14 May 2025 10:54:33 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Miroslav Lichvar <mlichvar@...hat.com>
Cc: LKML <linux-kernel@...r.kernel.org>, netdev@...r.kernel.org, Richard
 Cochran <richardcochran@...il.com>, Christopher Hall
 <christopher.s.hall@...el.com>, David Zage <david.zage@...el.com>, John
 Stultz <jstultz@...gle.com>, Frederic Weisbecker <frederic@...nel.org>,
 Anna-Maria Behnsen <anna-maria@...utronix.de>, Werner Abt
 <werner.abt@...nberg-usa.com>, David Woodhouse <dwmw2@...radead.org>,
 Stephen Boyd <sboyd@...nel.org>, Thomas Weißschuh
 <thomas.weissschuh@...utronix.de>, Kurt Kanzenbach <kurt@...utronix.de>,
 Nam Cao <namcao@...utronix.de>, Alex Gieringer <gieri@...utronix.de>
Subject: Re: [patch 00/26] timekeeping: Provide support for independent PTP
 timekeepers

On Wed, May 14 2025 at 09:12, Miroslav Lichvar wrote:
> On Tue, May 13, 2025 at 05:12:54PM +0200, Thomas Gleixner wrote:
>> This series addresses the timekeeping part by utilizing the existing
>> timekeeping and NTP infrastructure, which has been prepared for
>> multi-instance in recent kernels.
>
> This looks very interesting. I ran some quick tests and it seems to
> work as expected from the user space point of view. I can enable the
> clock and synchronize it to a PTP HW clock or the system REALTIME
> clock. ADJ_TICK works too.

Cool.

> To get accuracy and stability comparable to CLOCK_REALTIME, there will
> need to be some support for cross timestamping against CLOCK_REALTIME
> and/or PTP HW clocks, e.g. a variant of the PTP_SYS_OFFSET_PRECISE and
> PTP_SYS_OFFSET_EXTENDED ioctls where the target clock can be selected.

Yes, that's required, but for that to implement we need the core muck
first :)

> The "PTP" naming of these new clocks doesn't seem right to me though
> and I suspect it would just create more confusion. I don't see
> anything specific to PTP here. There is no timestamping of network
> packets, no /dev/ptp device, no PTP ioctls. To me they look like
> secondary or auxiliary system realtime clocks. I propose to rename
> them from CLOCK_PTP0-7 to CLOCK_REALTIME2-9, CLOCK_AUXILIARY0-7, or
> CLOCK_AUX0-7.

CLOCK_REALTIME2-9 would be weird as those clocks have not necessarily a
relationship to CLOCK_REALTIME. They can have a seperate resulting
frequency and starting point when they are soleley used for application
specific purposes within a network (think automation, automotive, audio
etc.).

CLOCK_AUX0-7 sounds really good to me and makes sense. I picked PTP
because that's where I was coming from. I'll rework that accordingly and
make the config enablement independent of PTP as well:

config POSIX_CLOCKS_AUX
       bool "Enable auxiliary POSIX clocks" if POSIX_TIMERS
       help
            Add blurb

and PTP can eventually select it (or not). Something like that.

Thanks,

        tglx