netdev - Re: [PATCH net-next RFC v4 4/5] net: Let the active time stamping layer be selectable.

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: <20230511231803.oylnku5iiibgnx3z@skbuf>
Date: Fri, 12 May 2023 02:18:03 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Köry Maincent <kory.maincent@...tlin.com>,
	netdev@...r.kernel.org, glipus@...il.com,
	maxime.chevallier@...tlin.com, vadim.fedorenko@...ux.dev,
	richardcochran@...il.com, gerhard@...leder-embedded.com,
	thomas.petazzoni@...tlin.com, krzysztof.kozlowski+dt@...aro.org,
	robh+dt@...nel.org, linux@...linux.org.uk
Subject: Re: [PATCH net-next RFC v4 4/5] net: Let the active time stamping
 layer be selectable.

On Thu, May 11, 2023 at 04:08:45PM -0700, Jakub Kicinski wrote:
> I think it's worth calling out that we may be touching most / all
> drivers anyway to transition them from the IOCTL NDO to a normal
> timestamp NDO.

Right, and figuring out how to deal with PHY timestamping in the new API
is "step 1.5" between creating that new API (Maxim's patch set) and
making the timestamping layer selectable (Köry's patch set).

> > But OTOH, if a macro-driver like DSA declares its interest in receiving
> > all timestamping requests, but then that particular DSA switch returns
> > -EOPNOTSUPP in the ndo_hwtstamp_set() handler, it would be silly for the
> > core to still "force the entry" and call phy_mii_ioctl() anyway - because
> > we know that's going to be broken.
> > 
> > So with "NDO returns -EOPNOTSUPP", I hope you don't mean *that* NDO
> > (ndo_hwtstamp_set()) but a previously unnamed one that serves the same
> > purpose as the capability bit - ndo_hey_are_you_interested_in_this_hwtstamp_request().
> > In that case, yes - with -EOPNOTSUPP we're back to "yolo".
> 
> Why can't we treat ndo_hwtstamp_set() == -EOPNOTSUPP as a signal 
> to call the PHY? ndo_hwtstamp_set() does not exist, we can give
> it whatever semantics we want.

Hmm, because if we do that, bridged DSA switch ports without hardware
timestamping support and without logic to trap PTP to the CPU will just
spew those PTP frames with PHY hardware timestamps everywhere, instead
of just telling the user hey, the configuration isn't supported?