Re: [RFC] y2038: HCI_TIME_STAMP with time64

From: Marcel Holtmann <marcel@holtmann.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Bluez mailing list <linux-bluetooth@vger.kernel.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	Johan Hedberg <johan.hedberg@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Deepa Dinamani <deepa.kernel@gmail.com>,
	Rich Felker <dalias@libc.org>, Guy Harris <guy@alum.mit.edu>
Subject: Re: [RFC] y2038: HCI_TIME_STAMP with time64
Date: Fri, 10 Jan 2020 18:52:41 +0100	[thread overview]
Message-ID: <14C7747D-E987-4A0A-AAA8-73B317B11656@holtmann.org> (raw)
In-Reply-To: <CAK8P3a1K79zGvi3hc4aw4vcsni1cx4u121OBHgWiaFSPxpA6ZQ@mail.gmail.com>

Hi Arnd,

>>> I noticed earlier this week that the HCI_CMSG_TSTAMP/HCI_TIME_STAMP
>>> interface has no time64 equivalent, as we apparently missed that when
>>> converting the normal socket timestamps to support both time32 and time64
>>> variants of the sockopt and cmsg data.
> ...
>>> When using HCI_TIME_STAMP on a 32-bit system with a time64
>>> libc, users will interpret the { s32 tv_sec; s32 tv_usec } layout of
>>> the kernel as { s64 tv_sec; ... }, which puts complete garbage
>>> into the timestamp regardless of whether this code runs before or
>>> after y2038. From looking at codesearch.debian.org, I found two
>>> users of this: libpcap and hcidump. There are probably others that
>>> are not part of Debian.
> ...
>>> 3. Add support for the normal SO_TIMESTAMPNS_NEW sockopt in
>>>  HCI, providing timestamps in the unambiguous { long long tv_sec;
>>>  long long tv_nsec; } format to user space, and change applications
>>>  to use that if supported by the kernel.
>> 
>> I have added SO_TIMESTAMP* to every Bluetooth socket a while back. And that should be used by the majority of the tools. One exception might by hcidump which has been replaced by btmon already anyway.
>> 
>> So I would not bother with HCI_TIME_STAMP fixing. We can do 2) if someone really still wants to use that socket option. However I am under the impression that 3) should be already possible.
> 
> Ok, excellent, I had not realized this works already.
> 
> I have now also checked
> https://github.com/the-tcpdump-group/libpcap/blob/master/pcap-bt-monitor-linux.c
> which uses SO_TIMESTAMP and then should work. I guess this is similar
> to what btmon does.
> 
> For libpcap that leaves
> https://github.com/the-tcpdump-group/libpcap/blob/master/pcap-bt-linux.c#L358
> 
> which needs a fairly simply fix on 32-bit architectures to copy the
> two 32-bit fields
> into the longer pkth.ts fields individually rather than using a memcpy.
> I've added Guy Harris to Cc, he seems to be the maintainer for this file
> according to the git history.
> 
> The same change is needed for
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/tools/hcidump.c#n233
> if there are any remaining users. I can send you a patch if you want.

please send a patch for hcidump if you have the time.

Regards

Marcel