linux-kernel - Re: [PATCH net-next] ptp: add vclock timestamp conversion IOCTL

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 13 Oct 2021 11:56:00 +0200
From:   Sebastien Laveze <sebastien.laveze@....nxp.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        yangbo.lu@....com, yannick.vignon@....nxp.com,
        rui.sousa@....nxp.com
Subject: Re: [PATCH net-next] ptp: add vclock timestamp conversion IOCTL

On Mon, 2021-10-11 at 05:58 -0700, Richard Cochran wrote:
> Here is a simple example that has no solution, AFAICT.
> 
> - Imagine one physical and one virtual clock based on it.
> 
> - A user space program using the virtual clock synchronizes to within
>   100 nanoseconds of its upstream PTP Domain.  So far, so good.
> 
> - Now a second program using the physical clock starts up, and
>   proceeds to measure, then correct the gross phase offset to its
>   upstream PTP Domain.
> 
> - The driver must now add, as your proposal entails, the reverse
>   correction into the virtual clock's timecounter/cyclecounter.
> - However, this particular physical clock uses a RMW pattern to
>   program the offset correction.
> 
> - Boom.  Now the duration of the RMW becomes an offset error in the
>   virtual clock.  The magnitude may be microseconds or even
>   milliseconds for devices behind slow MDIO buses, for example.
> 

My proposal includes handling PHC offset entirely in software. There is
no way (and we agree on this :)) to change the PHC offset without
impacting children virtual clocks.

Done in software, an offset adjustment has no impact at all on virtual
clocks (since it can always be done atomically, not RMW).

So with, no hardware clock phase adjustment and limited frequency
adjustments, we believe it can be made fully transparent to virtual
clocks. And that would improve the current limitation of no adjustment
all, and would unblock the support of features like Qbv for devices
with a single clock.

Thanks,
Sebastien