linux-kernel - Re: [PATCHv2 next] ptp: update gettimex64 to provide ts optionally in mono-raw base.

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: <87edaxudr8.ffs@tglx>
Date: Tue, 23 Apr 2024 02:24:59 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Mahesh Bandewar (महेश बंडेवार) <maheshb@...gle.com>, David Laight
 <David.Laight@...lab.com>
Cc: Netdev <netdev@...r.kernel.org>, Linux <linux-kernel@...r.kernel.org>,
 David Miller <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Eric
 Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Richard
 Cochran <richardcochran@...il.com>, Arnd Bergmann <arnd@...db.de>, Sagi
 Maimon <maimon.sagi@...il.com>, Jonathan Corbet <corbet@....net>, John
 Stultz <jstultz@...gle.com>, Mahesh Bandewar <mahesh@...dewar.net>
Subject: Re: [PATCHv2 next] ptp: update gettimex64 to provide ts optionally
 in mono-raw base.

On Mon, Apr 22 2024 at 15:04, Mahesh Bandewar (महेश बंडेवार) wrote:
> On Sun, Apr 21, 2024 at 11:27 AM David Laight <David.Laight@...lab.com> wrote:
>>
>> Isn't using CLOCK_REALTIME just a big bug?
>> As well as minor 'corrections' done by NTP it suffers from
>> major time-warps that can jump in either direction by arbitrary amounts.
>>
> Yes, this arbitrary jump in either direction is a problem and hence
> the proposed update. However, since it's a UAPI and there could be use
> cases that are happy with the current implementation, we can't break
> them. Of course the use case that I'm bringing in (and probably what
> you have in mind) differs but backward compatibility needs to be
> maintained.

It depends on what you are trying to do. You cannot adjust
CLOCK_REALTIME/TAI without knowing the current time, right?

So just declaring that this is a big bug and a problem is as wrong as it
gets. It's obviously not the right thing for all use cases, but that
makes the legitimate use cases not wrong.

>> This doesn't solve the problem of the NTP adjusted clock always
>> running slightly slow or fast.
>> The big NTP errors happen in the first (IIRC up to ~20 mins after boot)
>> when the system clock is being synchronised.
>
> Yes, a big step is a high possibility at the beginning (at boot) but
> smaller steps as well as ppm adjustments are real possibilities
> throughout and hence CLOCK_REALTIME and CLOCK_MONOTONIC are affected.
> By adding the timestamps in CLOCK_MONOTONIC_RAW (as proposed in this
> patch) should address this issue.
>
>> It really would be nice if those big adjustments didn't affect
>> CLOCK_MONATONIC. (as an example try sending RTP audio every 20ms)

They don't affect CLOCK_MONATONIC at all because there is no such clock :)

> Hmm, probably this is out of context for this patch and probably a
> question for the time maintainers / experts?

The quantity of the initial frequency adjustments depends on the
accuracy of the initial clock frequency calibration which is on most
sane systems within +/- 500ppm.

     500ppm of 20ms == 10us

If the clock calibration is off by a larger margin then that needs to be
fixed.

It's clearly documented that CLOCK_MONOTONIC and CLOCK_REALTIME (and
therefore CLOCK_BOOTTIME and CLOCK_TAI) are strictly based on the same
frequency and only differ by offsets. So there is nothing to fix and
change.

Thanks,

        tglx