netdev - Re: What is SOF_TIMESTAMPING_RX

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:	Tue, 4 Mar 2014 09:21:47 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Richard Cochran <richardcochran@...il.com>
Cc:	Network Development <netdev@...r.kernel.org>
Subject: Re: What is SOF_TIMESTAMPING_RX_HARDWARE?

On Tue, Mar 4, 2014 at 2:10 AM, Richard Cochran
<richardcochran@...il.com> wrote:
> On Mon, Mar 03, 2014 at 06:20:33PM -0800, Andy Lutomirski wrote:
>> AFAICT is sets SOCK_TIMESTAMPING_RX_HARDWARE, which appears to do
>> exactly nothing.  If I'm right, should I submit a patch documenting
>> that fact and removing the getsockopt/setsockopt implementations?
>
> Have you seen Documentation/networking/timestamping.txt?
>
>   SOF_TIMESTAMPING_TX/RX determine how time stamps are generated.
>   SOF_TIMESTAMPING_RAW/SYS determine how they are reported in the
>   following control message:

I read it and focused on this part:

SOF_TIMESTAMPING_RX_HARDWARE:  return the original, unmodified time stamp
                               as generated by the hardware
SOF_TIMESTAMPING_RX_SOFTWARE:  if SOF_TIMESTAMPING_RX_HARDWARE is off or
                               fails, then do it in software
SOF_TIMESTAMPING_RAW_HARDWARE: return original raw hardware time stamp
SOF_TIMESTAMPING_SYS_HARDWARE: return hardware time stamp transformed to
                               the system time base

which is somewhere between useless and incorrect.

>
> This is the API that was invented (not by me) to support HW time stamp
> reporting. I agree that it is confusing and complicated, but I don't
> think you can remove the flag as it is a firmly established API.
> Drivers do use this to advertise whether they support receive time
> stamps in hardware.

Huh?  It may well be firmly established that
SOF_TIMESTAMPING_RX_HARDWARE exists as a flag and gets returned by
getsockopt after being set by setsockopt.  But I can't find any
evidence at all that drivers indicate *via getsockopt* anything
whatsoever.

So maybe the documentation should change to:

SOF_TIMESTAMPING_RX_HARDWARE and SOF_TIMESTAMPING_RX_SOFTWARE do
nothing at all when set using setsockopt.  (setsockopt will allow them
to be set for backwards compatibility.)  Theese are only used by
ETHTOOL_GET_TS_INFO.

or something like that.

I'd write a patch to get rid of SOCK_TIMESTAMPING_RX_HARDWARE, etc,
but that might break a program that sets the flag in setsockopt and
expects it to be returned by getsockopt.

->
> AFAICT, the reason why setting this socket option is a noop is
> this. Once receive time stamping is enabled at the driver level,
> eligible skbs will get the information whether they want it or not.
> It would be more work to hide this from sockets which haven't enabled
> the option, and so we don't do it.

In theory, the driver could stop reporting timestamps if
SOF_TIMESTAMPING_RAW_HARDWARE: and SOF_TIMESTAMPING_SYS_HARDWARE
aren't set.  I don't see why SOF_TIMESTAMPING_RX_HARDWARE would make
any sense in this context.

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