netdev - Re: [RFC PATCH net-next 0/6] ptp: Support hardware clocks with additional free running time

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: <CANr-f5yecFHG9mjRTd4aKBNzKgVV_tbZ4VAKXkMe2qxAMb66Gg@mail.gmail.com>
Date:   Tue, 8 Mar 2022 20:49:03 +0100
From:   Gerhard Engleder <gerhard@...leder-embedded.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     yangbo.lu@....com, David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, mlichvar@...hat.com,
        Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH net-next 0/6] ptp: Support hardware clocks with
 additional free running time

> > ktime_to_cycles uses hwtstamp as key for the cache lookup. As long as
> > the PHC is monotonic, the key is unique. If the time of the PHC is set, then
> > the cache would be invalidated. I'm afraid that setting the PHC could lead to
> > wrong or missing timestamps. Setting the PHC in hardware, timestamp
> > generation in hardware, and cache invalidation in software would need to
> > be synchronized somehow.
>
> You can avoid errors even with a time jump:
>
> Make a variant (union) of skb_shared_hwtstamps to allow driver to
> provide an address or cookie instead of ktime_t.  Set a flag in the
> skbuff to signal this.
>
> Let the Rx path check the flag and fetch the time stamp by callback
> with the address/cookie.
>
> > For TX it is known which timestamp is required. So I would have to find a way
> > to detect which timestamp shall be filled into hwtstamp.
>
> How about tx_flags in struct skb_shared_info ?

I will try to make an implementation!

Shall I use tx_flags in struct skb_shared_info for both, TX and RX? Or should
I use flags in struct skb_shared_info for address/cookie signalisation?

3 of 8 flags are unused in tx_flags. It may be possible to use the same flag for
TX and RX. Is it worth it trying to save flags?

For TX it signals "fill cycle based timestamp" and could be called
SKBTX_HW_CSTAMP.

For RX it signals "hwtstamp is an address/cookie" and could be called
SKBFL_TSTAMP_COOKIE.

Thank you!
Gerhard