netdev - Re: [PATCH net-next v3 1/5] net-timestamp: extend SCM

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]

Date:	Thu, 24 Jul 2014 19:05:14 -0400
From:	Willem de Bruijn <willemb@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, Eric Dumazet <eric.dumazet@...il.com>,
	Richard Cochran <richardcochran@...il.com>,
	Chad Reese <kreese@...iumnetworks.com>,
	ddaney@...iumnetworks.com
Subject: Re: [PATCH net-next v3 1/5] net-timestamp: extend SCM_TIMESTAMPING
 ancillary data struct

>> That does not address legacy application dependencies on syststamp.
>> Even with a PTP device, it is unclear whether anyone would invest time
>> to convert their application to use it. The most relevant code I could
>> find is cavium ptp-1588v2 on github. That configures SO_TIMESTAMPING
>> to generate both raw + sys tstamps and preferentially reads the first.
>> If this is the only known octeon timestamping user, then it would be
>> just as safe to simply remove syststamp.
>
> The kernel would simply saw that adjusted HW timestamps are not
> supported, the application has to accomodate the possibility of
> needing to use one of the other timestamping flavors.

Cavium's PTP library already programs the device PTP clock,
just not through the standard interface. It appears to map the
memory addresses CVMX_MIO_.. directly. In any case, it
will gracefully handle the loss of syststamp.

I doubt that there are other users of this Octeon interface, but
if so, they can reasonably be expected to do the same and
rely on the same legacy Octeon PTP clock interface +
hwtstamp as alternative. Is that enough justification to remove
syststamp without patching the driver to implement
ptp_clock_info?

Cleanup would be two patches: one to revert the relevant
code in the octeon driver (mostly, ptp_to_ktime), and a
follow-up to remove the core code now that the last user
is gone.
--
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