netdev - Re: bnxt_en: Incorrect tx timestamp report

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

Message-ID: <CAGtf3iahrq5pynj7cbWsuY=RSRApciCf5N9wHbUf0SpPuh5Q0A@mail.gmail.com>
Date: Thu, 20 Mar 2025 17:14:38 +0200
From: Kamil Zaripov <zaripov-kamil@...ide.ai>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org
Subject: Re: bnxt_en: Incorrect tx timestamp report

Yes, I know, but the issue is that it seems there is no way to read
upper 48-63 bits except receiving it from
ASYNC_EVENT_CMPL_EVENT_ID_PHC_UPDATE or setting it inside settime64
call. See comments to the
https://github.com/torvalds/linux/commit/24ac1ecd524065cdcf8c27dc85ae37eccce8f2f6
commit.

Kamil.


On Thu, Mar 20, 2025 at 5:12 PM Kamil Zaripov <zaripov-kamil@...ide.ai> wrote:
>
> > > 2. Is there a method available to read the complete 64-bit PHC
> > > counter to mitigate the observed problem of 2^48-nanosecond time
> > > jumps?
> >
> > The usual workaround is to read the upper part, the lower part, and
> > the upper part again. If you get two different values for the upper
> > part, do it all again, until you get consistent values.
>
> Yes, I know, but the issue is that it seems there is no way to read upper 48-63 bits except receiving it from ASYNC_EVENT_CMPL_EVENT_ID_PHC_UPDATE or setting it inside settime64 call. See comments to the https://github.com/torvalds/linux/commit/24ac1ecd524065cdcf8c27dc85ae37eccce8f2f6 commit.
>
> Kamil.
>
>
> On Thu, Mar 20, 2025 at 4:48 PM Andrew Lunn <andrew@...n.ch> wrote:
>>
>> > 2. Is there a method available to read the complete 64-bit PHC
>> > counter to mitigate the observed problem of 2^48-nanosecond time
>> > jumps?
>>
>> The usual workaround is to read the upper part, the lower part, and
>> the upper part again. If you get two different values for the upper
>> part, do it all again, until you get consistent values.
>>
>> Look around other PTP drivers, there is probably code you can
>> copy/paste.
>>
>>         Andrew