netdev - Re: [PATCH net-next] vlan: Pass ethtool get_ts

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: <20141123160533.GA4562@netboy>
Date:	Sun, 23 Nov 2014 17:05:35 +0100
From:	Richard Cochran <richardcochran@...il.com>
To:	Ben Hutchings <ben@...adent.org.uk>
Cc:	netdev@...r.kernel.org, David Miller <davem@...emloft.net>,
	Stefan Sørensen 
	<stefan.sorensen@...ctralink.com>
Subject: Re: [PATCH net-next] vlan: Pass ethtool get_ts_info queries to real
 device.

On Sun, Nov 23, 2014 at 03:15:12AM +0000, Ben Hutchings wrote:
> This assumes that the same PTP capabilities apply to VLAN-tagged frames.
> I don't think it's at all safe to assume that RX filter modes other than
> HWTSTAMP_FILTER_ALL will include VLAN-tagged frames.  I think it is
> necessary to define additional modes that explicitly include VLAN-tagged
> frames.

Unsafe? How?

Do you mean that some HW cannot identify and time stamp PTP frames
when VLAN tagged? That is surely disappointing for people who shell
out money for such cards, but it is hardly unsafe.

> I also disagree in general that reconfiguring a VLAN device should make
> changes to the underlying device that affect more than just that VLAN,
> i.e. SIOCSHWTSTAMP should not be passed through.  SIOCGHWTSTAMP could be
> passed through, but rx_filter would need adjustment (VLAN-tagged modes
> on the underlying devices become untagged modes on the VLAN device).

The whole filter list with every last combination (at least, the ones
at the time) came directly from a early, limited HW design.  Sane,
modern PTP hardware provides time stamps regardless of whether a frame
is VLAN tagged or not. I don't see any reason not to make our stack
even more ugly just to cater to broken hardware.

I have nothing against adding VLAN to the SIOCGHWTSTAMP list, because
the hardware people *really* use all have:

	HWTSTAMP_TX_ON, and
	HWTSTAMP_FILTER_ALL, or 
	HWTSTAMP_FILTER_PTP_V2_EVENT,

So adding more won't hurt. (But it won't help either. If your HW
cannot time stamp Layer2 and you transmit Layer2, you simply never get
a time stamp.)

But please don't hold up progress just for this sort of thing.

Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html