netdev - Re: [PATCH net-next 1/9] ptp: Clarify ptp_clock_info .adjphase expects an internal servo to be used

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: <87mt1w5mec.fsf@nvidia.com>
Date: Mon, 22 May 2023 10:03:23 -0700
From: Rahul Rameshbabu <rrameshbabu@...dia.com>
To: Richard Cochran <richardcochran@...il.com>
Cc: netdev@...r.kernel.org,  Saeed Mahameed <saeed@...nel.org>,  Gal
 Pressman <gal@...dia.com>,  Tariq Toukan <tariqt@...dia.com>,  "David S.
 Miller" <davem@...emloft.net>,  Jakub Kicinski <kuba@...nel.org>,  Jacob
 Keller <jacob.e.keller@...el.com>
Subject: Re: [PATCH net-next 1/9] ptp: Clarify ptp_clock_info .adjphase
 expects an internal servo to be used

Hi Richard,

I have a v2 prepared. I have just one question left before sending that
it out.

On Thu, 11 May, 2023 17:51:47 -0700 Richard Cochran <richardcochran@...il.com> wrote:
> On Thu, May 11, 2023 at 01:20:45PM -0700, Rahul Rameshbabu wrote:
>
>> If the PHC does not restore the frequency, won't the value cached in the
>> ptp stack in the kernel become inaccurate compared to the frequency
>> change induced by the '.adjphase' call?
>
> If the HW implements a PI controller, and if it has converged, then
> the current frequency will be close to the remote time server's.

This point makes sense to me. However, I have a concern about the case
where the linuxptp servo has not had a chance to make a single frequency
adjustment (0 ppb) and .adjphase/LOCKED_STABLE state is initially
called/reached. After converging, the frequency will be close to the
remote time's server's frequency, but that frequency will likely not be
0 ppb. If .adjfine had been called previously, the difference between
the remote time server's frequency and the cached frequency in the ptp
stack would likely be significantly closer. That said, do you think it
makes sense to have some kind of API that gives information about the
in-HW controller such as the frequency offset it operated? Or maybe in
general an API in the future for introspecting the state of this in-HW
servo?

>
>> This concern is why I added this
>> clause in the documentation. Let me know if my understanding is off with
>> regards to this. I think we had a similar conversation on this
>> previously in the mailing list.
>> 
>> https://lore.kernel.org/netdev/Y88L6EPtgvW4tSA+@hoboy.vegasvil.org/
>
> I guess it depends on the HW algorithm and the situation.  But I don't
> think there is a "rule" that always gets the best result.

Agreed. I do not think enforcing the PHC to restore the frequency to the
value before .adjphase is called would be helpful. This preserves the
integrity of the cached value in the kernel stack, but that is not
helpful since we can potentially see an initial growing error in the
offset between the remote server's time and the PHC's time after making
this frequency reversion.

>
> Thanks,
> Richard

-- Rahul Rameshbabu