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 16:50:53 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	willemb@...gle.com
Cc:	netdev@...r.kernel.org, eric.dumazet@...il.com,
	richardcochran@...il.com, kreese@...iumnetworks.com,
	ddaney@...iumnetworks.com
Subject: Re: [PATCH net-next v3 1/5] net-timestamp: extend SCM_TIMESTAMPING
 ancillary data struct

From: Willem de Bruijn <willemb@...gle.com>
Date: Thu, 24 Jul 2014 19:05:14 -0400

>>> 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.

I'm not sure I understand, can users still get hardware timestamps
from Octeon cards after such a change?  Unless I misunderstand, the
only thing left available will be software timestamps, right?
--
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