linux-kernel - Re: [PATCH net-next] gve: Correctly report software timestamping capabilities

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: <20240410061928.712ff9a3@kernel.org>
Date: Wed, 10 Apr 2024 06:19:28 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Rahul Rameshbabu <rrameshbabu@...dia.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>, John Fraker
 <jfraker@...gle.com>, netdev@...r.kernel.org, Praveen  Kaligineedi
 <pkaligineedi@...gle.com>, Harshitha Ramamurthy <hramamurthy@...gle.com>,
 Shailend Chand <shailend@...gle.com>, Willem de  Bruijn
 <willemb@...gle.com>, "David S. Miller" <davem@...emloft.net>, Junfeng Guo
 <junfeng.guo@...el.com>, Ziwei Xiao <ziweixiao@...gle.com>, Jeroen de Borst
 <jeroendb@...gle.com>, linux-kernel@...r.kernel.org,
 kory.maincent@...tlin.com, andrew@...n.ch, richardcochran@...il.com
Subject: Re: [PATCH net-next] gve: Correctly report software timestamping
 capabilities

On Tue, 09 Apr 2024 21:40:46 -0700 Rahul Rameshbabu wrote:
> > My gut tells me we force drivers to set the ethtool op because
> > while at it they will probably also implement tx stamping.  
> 
> I think the logic should be the other way (in terms of the
> relationship). A call to skb_tx_timestamp should throw a warning if the
> driver does not advertise its timestamping capabilities. This way, a
> naive netdev driver for some lightweight device does not need to worry
> about this. I agree that anyone implementing tx timestamping should have
> this operation defined. An skb does not contain any mechanism to
> reference the driver's ethtool callback. Maybe the right choice is to
> have a ts capability function registered for each netdev that can be
> used by the core stack and that powers the ethtool operation as well
> instead of the existing callback for ethtool?

Adding a check which only need to runs once in the lifetime of
the driver to the fastpath may be a little awkward. Another option
would be a sufficiently intelligent grep, which would understand
which files constitute a driver. At which point grepping for 
the ethtool op and skb_tx_timestamp would be trivial?