netdev - Re: [PATCH net-next 1/2] net: extend ndo_get

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

Message-ID: <CAPREpbaova8T=E1jiyhMZugiw0ooTLD7EE147NKxHAMSbVkA9Q@mail.gmail.com>
Date: Tue, 20 Jan 2026 13:23:17 -0500
From: Kevin Yang <yyd@...gle.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Willem de Bruijn <willemb@...gle.com>, Harshitha Ramamurthy <hramamurthy@...gle.com>, 
	Andrew Lunn <andrew+netdev@...n.ch>, David Miller <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, 
	Joshua Washington <joshwash@...gle.com>, Gerhard Engleder <gerhard@...leder-embedded.com>, 
	Richard Cochran <richardcochran@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/2] net: extend ndo_get_tstamp for other
 timestamp types

Just to clarify your suggestion is that drivers should expose their internal
time/cyclecounter (along with necessary locking)? And then have a
core kernel helper performs the common conversion from the timestamp
to REALTIME(or MONOTONIC)?

If that is the case, looking at gve_get_tstamp in this series, there is
little code to de-duplicate: just a lock and timecounter_cyc2time.
Exposing those internals would likely be more complex.

Also some NICs/drivers might already provide skb_hwtstamps() in REALTIME.
Only the driver knows the device clock's details and whether
conversion is needed.
ndo_get_tstamp can help hide these details.

On Mon, Jan 19, 2026 at 2:57 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Thu, 15 Jan 2026 22:22:59 +0000 Kevin Yang wrote:
> > Reviewed-by: Willem de Bruijn <willemb@...gle.com>
>
> Other than expediency why implementing this in drivers makes sense?
> There will be very little driver specific logic here.
>
> After thinking about it for 1 minute my intuition would be for drivers
> to just expose necessary information, in-kernel consumers should
> "enable" the sync for all netdevs during init, and then convert
> the timestamps into REALTIME / MONOTONIC by calling some helper?
>
> Also AI code review says:
>
> > +             mult = mult_frac(GVE_HWTS_REAL_CC_NOMINAL,
> > +                              real_ns - priv->ts_real.last_sync_ns,
> > +                              priv->last_sync_nic_counter - prev_nic);
>
> Can this divide by zero?
Will fix this in v2.
> --
> pw-bot: cr