As discussed before, I tried using the rebootstrap tool [1] to see what
problems come up once the entire distro gets rebuilt. Based on Lukasz'
recommendation, I tried the 'y2038_edge' branch with his experimental
glibc patches [2], using commit c2de7ee9461 dated 2020-02-17.
Here is a rough summary of what I tried, what worked, and what problems
I ran into:
* Building a Debian package from this was fairly straightforward, using
the 2.31 branch in the package git repository[3] after replacing the
debian/patches/git-updates.diff file with one generated from [2] and
disabling the hurd patches because of conflicts.
* After installing the modified x86 glibc package, I ran into a runtime
bug in [4], which needs to pass AT_FDCWD instead of 0 to avoid
ENOTDIR errors.
* Bootstrapping a regular time32 Debian armhf with this libc took me
a few days to get right, but that was mostly for getting familiar
with rebootstrap and running into known issues unrelated to time64
or the glibc changes.
* Actually building a time64 version of glibc turned out to be
harder, including some issues discussed on the libc mailing list[5]:
- Always setting -D_TIME_BITS=64 in the global compiler flags for
the distro breaks both the native 64-bit (x86_64) build and the
32-bit build, as glibc itself expects to be built without this.
- Removing the time32 symbols from the glibc shared object did not
work as they are still used (a lot) internally, and by the testsuite.
- I tried converting all the internal symbols to use the time64
variants with the correct types (e.g. __clock_gettime64() instead
of __clock_gettime()), but then ran into a lot of APIs that take
timespec/timeval/... arguments and pass them down into internal
functions. These seem to all be bugs that require adding a time64
version of the external ABI.
- After I abandoned that approach, I continued with a simple
patch to features.h that sets _TIME_BITS/_FILE_OFFSET_BITS based on
'#if !defined _LIBC && __TIMESIZE == 32', which ignores the bugs I
found earlier but got me a lot further.
- Building the i386 glibc with that patch, I ran into over 150
testsuite failures [6]. This looked like there was a fundamental
mistake on my side, but after I looked into a few of the failures,
most seemed to be either glibc or testsuite bugs that have to be
addressed individually. I considered giving up at this point,
but as Lukasz has said that he had successfully built a working
system using Yocto, I kept going anyway and marked these all as
expected failures in the debian package.
* There are a couple of noteworthy issues in glibc-y2038 I'd like to
point out in particular, though I'm sure these are not the only
important ones:
- The clock_nanosleep() prototype needed a '__THROW' annotation
to complete the build.
- The nptl and sunrpc portions have numerous interfaces with
'timeval' or 'timespec' arguments that each cause an ABI break.
- stat()/fstat()/lstat(), nanosleep(), wait3()/wait4(), ppoll_chk()
are some of the other interfaces that take a time_t based
argument and need to grow a time64 version to avoid an ABI mismatch.
- The timeval prototype appears to be broken, as it's missing
padding on architectures without native alignment of __time64
(e.g. i386) and on all big-endian architectures.
- some testcases hang in futex_wait() or clock_nanosleep()
because of incorrect timeout arguments, presumably from type
mismatches.
* There is an open question regarding the name of the Debian
architecture. For my experiments, I kept using the 'armhf' name
unmodified, though there seems to be a general feeling that using a
different name would be required to address the broad incompatibilities
between time32 and time64 versions of all the libraries in the
distro. Gradually changing them won't work because of the timeline and
the number of affected libraries. However, the new name of the distro
also implies having a distinct target triplet, which must then be known
by glibc along with everything else using config.guess/config.sub. I
expect this topic to require a lot more discussion.
* Continuing with the rebootstrap build despite the known glibc issues
and the open question on the architecture name went surprisingly
well, only two out of the 152 source packages I built had
compile-time problems:
- building the final gcc failed in libsanitizer, which has
compile-time checks to ensure some libc data structures have the
expected layout. It noticed that 'struct timeb' and 'struct dirent'
are different based on _TIME_BITS and _FILE_OFFSET_BITS. I disabled
the checks to be able to continue. To this properly, the library
has to learn about the new data structures as well. I opened a
bug report against the library[7].
- libpreludecpp12 failed to build because of checks for changes
in the exported functions, which are different with time64.
I disabled the checks. Once we have agreed on a new debian
architecture name, the symbols can be made arch specific.
* After everything was built, I tried installing the packages into
a chroot with qemu-debootstrap, which failed because I had
configured the glibc to assume it's running on a new kernel
while the qemu-user binary I had lacks the new syscalls.
I believe this is fixed in upstream qemu, but did not try that.
* Trying to install again I used a clean debian-arm64 installation
running in qemu-system-aarch64, and attempted installing the
armhf packages using a regular debootstrap, running the 32-bit
binaries in compat mode of a recent arm64 kernel. This partially
worked and I could chroot into the system and use a shell, but
ultimately the debootstrap did not complete because of errors.
I saw that 'tar' had failed because of the stat() glibc ABI mismatch
breaking its private gnulib fdutimens() implementation, and this is
where I gave up.
I have spent more time on this now than I had planned, and don't expect
to do further work on it anytime soon, but I hope my summary is useful
to others that are going to need this later. I can obviously share
my patches and build artifacts if anyone needs them. There are two
additional approaches that would likely get a Debian bootstrap further,
but that I have not tried as they were previously dismissed:
* Adding a time64 armhf as a separate (incompatible) target in glibc
that defines __TIMESIZE==64 and a 64-bit __time_t would avoid
most of the remaining ABI issues and put armhf-time64 in the same
category as riscv32 and arc, but this idea was so far rejected by the
glibc maintainers. Depending on how hard this turns out to be,
it could be used to get to the point of self-hosting though, and
help find time64 related bugs in the rest of the distro.
* Doing the bootstrap using a musleabihf target instead of gnueabihf
would avoid the current issues internal to glibc-y2038, but instead
lead to new problems with packages that do not currently work with
musl. Adelie Linux has shown that it's already possible to build
a useful distro using musl and time64[8], and this would
sidestep the question of the target triplet. While it would also
help find and fix additional bugs in packages, and make an
interesting unoffical Debian target, I don't see it replacing
the existing armhf port any time soon.
For additional information about the Debian plans, see the
article on LWN[9] that summarizes the discussion started by
Steve McIntyre [10].
Arnd
[1] https://wiki.debian.org/HelmutGrohne/rebootstrap
[2] https://github.com/lmajewski/y2038_glibc/tree/y2038_edge
[3] https://salsa.debian.org/glibc-team/glibc/-/tree/glibc-2.31
[4] https://github.com/lmajewski/y2038_glibc/commit/2f72ea2b6f6ee
[5] https://sourceware.org/pipermail/libc-alpha/2020-February/111375.html
[6] https://pastebin.com/fJYV2stF
[7] https://bugs.llvm.org/show_bug.cgi?id=45138
[8] https://wiki.adelielinux.org/wiki/Project:Time64
[9] https://lwn.net/Articles/812767/
[10] https://lwn.net/ml/debian-devel/20200204131410.GF3043@tack.einval.com/
On Mon, Mar 16, 2020 at 11:12 PM Lukasz Majewski <lukma(a)denx.de> wrote:
> > On Fri, Mar 13, 2020 at 9:22 PM Rich Felker <dalias(a)libc.org> wrote:
> > > > - Removing the time32 symbols from the glibc shared object did
> > > > not work as they are still used (a lot) internally, and by the
> > > > testsuite.
> > >
> > > That they're used internally sounds like a major problem; anywhere
> > > they're being used internally potentially has hidden Y2038 bugs.
> > > This is also why I'm concerned about glibc's approach of not
> > > building itself with _TIME_BITS=64, and just undefining it or doing
> > > something else in the wrapper files for the legacy time32 symbols.
> >
> > I thought this was the long-term plan. Working on the ABI first and
> > then changing the implementation may help speed up the timeline
> > before distro-level work can start, but OTOH removing all the 32-bit
> > codepaths from the implementation first makes it more likely to find
> > all relevant bits.
>
> If I understood the question correctly - the problem is with having
> glibc ABI consistent. This requires having 64 bit types for relevant
> functions. For example the __clock_settime64 accepts struct
> __timespec64 parameter which:
>
> - Is aliased to "normal" struct timespec on machines with
> __WORDSIZE==64 (x32 is a special case)
>
> - The struct __timespec64 is used on 32 bit machines
>
> As a result the glibc is ready to handle 64 bit time always (with
> clock_settime on __WORDSIZE==64 or clock_settime64 otherwise), as
> exported struct timespec fields size vary depending on the machine for
> which glibc is built.
I think we all understand the need to duplicate each interface that
passes a data type derived from time_t, and how the aliasing works,
The point above is purely for the internal implementation. The approach
that I have picked for the kernel and Rich did for musl was that
internal code never sees the old __time_t definition for any data
structure or function call, those are only used to define the wrappers
for 32-bit architectures that provide the legacy interfaces.
Arnd
[some mailing lists appear to have classified the earlier mail as spam,
it was quite long and contained a lot of links. See
https://lists.debian.org/debian-arm/2020/03/msg00032.html for the
start of the thread if you did not get that]
On Wed, Mar 11, 2020 at 3:37 PM Lukasz Majewski <lukma(a)denx.de> wrote:
> > - stat()/fstat()/lstat(), nanosleep(), wait3()/wait4(), ppoll_chk()
> > are some of the other interfaces that take a time_t based
> > argument and need to grow a time64 version to avoid an ABI
> > mismatch.
>
> The stat() and friends will use statx internally, which supports 64 bit
> time from the outset.
> Unfortunately, it hasn't been yet converted.
>
> As statx was added in 4.1 (IIRC) - after the minimal supported Linux
> kernel version is bumped to this version (from 3.2 as now) it all will
> be fixed.
The problem I had with these was not on the kernel API side (I
still have CONFIG_COMPAT_32BIT_TIME enabled for now) but
on the application side. In particular, the 'struct stat' definition
(when __USE_XOPEN2K8 is defined) contains
struct timespec st_atim;
and similar fields that are interpreted using 64-bit time_t in the
application including the header, but with 32-bit time_t inside of
the ___fxstat64() implementation in glibc. The problem is caused
by the mismatched ABI, not by the time_t overflow, in the same
way that happens in the nptl library callers and in the other interfaces
I mentioned.
This is also what seems to cause most of the testcase failures
when the tests are built with __TIME_BITS=64.
> > - The timeval prototype appears to be broken, as it's missing
> > padding on architectures without native alignment of __time64
> > (e.g. i386) and on all big-endian architectures.
> >
>
> You mean the one "exported" to the system or one, which is internal to
> glibc (from ./include/time.h)?
I mean in the installed headers, where I get (after preprocessing)
typedef long long __time64_t;
typedef long __suseconds_t;
struct timeval
{
__time64_t tv_sec;
__suseconds_t tv_usec;
};
On i386 and m68k, this leads to a 12 byte structure when the kernel
interfaces expect a 16 byte structure. All other 32-bit architectures add
four byte padding at the end, so the size is correct, but on big-endian
systems, kernel also expects padding *before* tv_usec, in the same
way as the timespec definition does. IIRC the best way to handle this
is with a 64-bit suseconds_t, e.g. by adding a __suseconds64_t
defined the same way as __time64_t.
> > I have spent more time on this now than I had planned, and don't
> > expect to do further work on it anytime soon, but I hope my summary
> > is useful to others that are going to need this later. I can
> > obviously share my patches and build artifacts if anyone needs them.
>
> Could you upload them to any server? (kernel.org or github)?
I have uploaded the modified debian-glibc and rebootstrap
sources to https://git.linaro.org/people/arnd/ now, this should
be all that's needed to recreate the build, using these steps:
- build an x86-64 debian glibc-2.31 package (binary plus source)
based on the glibc package data
- create a pbuilder instance with that available as a source to apt
- log into the pbuilder and run the modified bootstrap.sh according
to information on the pbuilder web page.
The binary packages I created are not as useful, as they would
not work with any build of glibc, neither the version I built, nor
any fixed one. I could find a way to send that to you in private,
but it's hundreds of megabytes.
Unfortunately I lost the build logs during a crash yesterday.
> > There are two additional approaches that would likely get a Debian
> > bootstrap further, but that I have not tried as they were previously
> > dismissed:
> >
> > * Adding a time64 armhf as a separate (incompatible) target in glibc
> > that defines __TIMESIZE==64 and a 64-bit __time_t would avoid
> > most of the remaining ABI issues and put armhf-time64 in the same
> > category as riscv32 and arc, but this idea was so far rejected by
> > the glibc maintainers.
>
> As fair as I know riscv32 and arc will use generic syscall interface.
> The arm32 bit doesn't support it - so the code from those two
> aforementioned ports will not be used.
The differences between the generic syscall interface and the arm
version are much smaller than ABI differences between the ABIs
for 32-bit __time_t and the __time_t == __time64_t version.
In particular, as such a new port could mandate a minimum kernel
of v5.1, it could just use all the time64 syscalls, the split sysvipc
and statx as a baseline.
Arnd
The following changes since commit 77b9040195dea3fcddf19e136c9e99a501351778:
compat_ioctl: simplify the implementation (2020-01-03 09:42:52 +0100)
are available in the Git repository at:
git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git
tags/compat-ioctl-fix
for you to fetch changes up to 0a061743af93f472687b8c69b0d539d1f12f3fd2:
compat_ioctl: fix FIONREAD on devices (2020-02-08 18:02:54 +0100)
----------------------------------------------------------------
compat-ioctl fix for v5.6
One patch in the compat-ioctl series broke 32-bit rootfs for multiple
people testing on 64-bit kernels. Let's fix it in -rc1 before others
run into the same issue.
----------------------------------------------------------------
Arnd Bergmann (1):
compat_ioctl: fix FIONREAD on devices
fs/ioctl.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a:
Linux 5.5-rc1 (2019-12-08 14:57:55 -0800)
are available in the Git repository at:
git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git
tags/y2038-drivers-for-v5.6-signed
for you to fetch changes up to c4e71212a245017d2ab05f322f7722f0b87a55da:
Revert "drm/etnaviv: reject timeouts with tv_nsec >= NSEC_PER_SEC"
(2020-01-28 23:24:23 +0100)
----------------------------------------------------------------
y2038: core, driver and file system changes
These are updates to device drivers and file systems that for some reason
or another were not included in the kernel in the previous y2038 series.
I've gone through all users of time_t again to make sure the kernel is
in a long-term maintainable state, replacing all remaining references
to time_t with safe alternatives.
Some related parts of the series were picked up into the nfsd, xfs,
alsa and v4l2 trees. A final set of patches in linux-mm removes the now
unused time_t/timeval/timespec types and helper functions after all five
branches are merged for linux-5.6, ensuring that no new users get merged.
As a result, linux-5.6, or my backport of the patches to 5.4 [1], should
be the first release that can serve as a base for a 32-bit system designed
to run beyond year 2038, with a few remaining caveats:
- All user space must be compiled with a 64-bit time_t, which will be
supported in the coming musl-1.2 and glibc-2.32 releases, along with
installed kernel headers from linux-5.6 or higher.
- Applications that use the system call interfaces directly need to be
ported to use the time64 syscalls added in linux-5.1 in place of the
existing system calls. This impacts most users of futex() and seccomp()
as well as programming languages that have their own runtime environment
not based on libc.
- Applications that use a private copy of kernel uapi header files or
their contents may need to update to the linux-5.6 version, in
particular for sound/asound.h, xfs/xfs_fs.h, linux/input.h,
linux/elfcore.h, linux/sockios.h, linux/timex.h and linux/can/bcm.h.
- A few remaining interfaces cannot be changed to pass a 64-bit time_t
in a compatible way, so they must be configured to use CLOCK_MONOTONIC
times or (with a y2106 problem) unsigned 32-bit timestamps. Most
importantly this impacts all users of 'struct input_event'.
- All y2038 problems that are present on 64-bit machines also apply to
32-bit machines. In particular this affects file systems with on-disk
timestamps using signed 32-bit seconds: ext4 with ext3-style small
inodes, ext2, xfs (to be fixed soon) and ufs.
Changes since v1 [2]:
- Add Acks I received
- Rebase to v5.5-rc1, dropping patches that got merged already
- Add NFS, XFS and the final three patches from another series
- Rewrite etnaviv patches
- Add one late revert to avoid an etnaviv regression
[1] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=…
[2] https://lore.kernel.org/lkml/20191108213257.3097633-1-arnd@arndb.de/
----------------------------------------------------------------
Arnd Bergmann (21):
fat: use prandom_u32() for i_generation
dlm: use SO_SNDTIMEO_NEW instead of SO_SNDTIMEO_OLD
xtensa: ISS: avoid struct timeval
um: ubd: use 64-bit time_t where possible
acct: stop using get_seconds()
tsacct: add 64-bit btime field
packet: clarify timestamp overflow
hostfs: pass 64-bit timestamps to/from user space
hfs/hfsplus: use 64-bit inode timestamps
drm/msm: avoid using 'timespec'
drm/etnaviv: reject timeouts with tv_nsec >= NSEC_PER_SEC
drm/etnaviv: avoid deprecated timespec
sunrpc: convert to time64_t for expiry
nfs: use time64_t internally
nfs: fix timstamp debug prints
nfs: fscache: use timespec64 in inode auxdata
y2038: remove obsolete jiffies conversion functions
y2038: rename itimerval to __kernel_old_itimerval
y2038: sparc: remove use of struct timex
y2038: sh: remove timeval/timespec usage from headers
Revert "drm/etnaviv: reject timeouts with tv_nsec >= NSEC_PER_SEC"
arch/sh/include/uapi/asm/sockios.h | 4 +-
arch/sparc/kernel/sys_sparc_64.c | 33 ++++++------
arch/um/drivers/cow.h | 2 +-
arch/um/drivers/cow_user.c | 7 +--
arch/um/drivers/ubd_kern.c | 10 ++--
arch/um/include/shared/os.h | 2 +-
arch/um/os-Linux/file.c | 2 +-
.../platforms/iss/include/platform/simcall.h | 4 +-
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 11 ++--
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 11 ++--
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 4 +-
drivers/gpu/drm/etnaviv/etnaviv_gem.h | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 +-
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 5 +-
drivers/gpu/drm/msm/msm_drv.h | 3 +-
fs/dlm/lowcomms.c | 6 +--
fs/fat/inode.c | 3 +-
fs/hfs/hfs_fs.h | 28 ++++++++---
fs/hfs/inode.c | 4 +-
fs/hfsplus/hfsplus_fs.h | 28 +++++++++--
fs/hfsplus/inode.c | 12 ++---
fs/hostfs/hostfs.h | 22 ++++----
fs/hostfs/hostfs_kern.c | 15 +++---
fs/nfs/fscache-index.c | 6 ++-
fs/nfs/fscache.c | 18 ++++---
fs/nfs/fscache.h | 8 +--
fs/nfs/nfs4xdr.c | 10 ++--
include/linux/jiffies.h | 20 --------
include/linux/sunrpc/cache.h | 42 +++++++++-------
include/linux/sunrpc/gss_api.h | 4 +-
include/linux/sunrpc/gss_krb5.h | 2 +-
include/linux/syscalls.h | 9 ++--
include/uapi/linux/acct.h | 2 +
include/uapi/linux/taskstats.h | 6 ++-
include/uapi/linux/time_types.h | 5 ++
include/uapi/linux/timex.h | 2 +
kernel/acct.c | 4 +-
kernel/time/itimer.c | 18 +++----
kernel/time/time.c | 58 ++--------------------
kernel/tsacct.c | 9 ++--
net/packet/af_packet.c | 27 ++++++----
net/sunrpc/auth_gss/gss_krb5_mech.c | 12 +++--
net/sunrpc/auth_gss/gss_krb5_seal.c | 8 +--
net/sunrpc/auth_gss/gss_krb5_unseal.c | 6 +--
net/sunrpc/auth_gss/gss_krb5_wrap.c | 16 +++---
net/sunrpc/auth_gss/gss_mech_switch.c | 2 +-
net/sunrpc/auth_gss/svcauth_gss.c | 6 +--
net/sunrpc/cache.c | 16 +++---
net/sunrpc/svcauth_unix.c | 10 ++--
49 files changed, 283 insertions(+), 266 deletions(-)
musl is moving to a default of 64-bit time_t on all architectures,
glibc will follow later. This breaks reading timestamps through cmsg
data with the HCI_TIME_STAMP socket option.
Change both copies of hcidump to work on all architectures. This also
fixes x32, which has never worked, and carefully avoids breaking sparc64,
which is another special case.
I have only compiled this on one architecture, please at least test
it to ensure there are no regressions. The toolchain binaries from
http://musl.cc/ should allow testing with a 64-bit time_t, but it may
be hard to build all the dependencies first.
libpcap has the same bug and needs a similar fix to work on future
32-bit Linux systems. Everything else apparently uses the generic
SO_TIMESTAMP timestamps, which work correctly when using new enough
kernels with a time64 libc.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
monitor/hcidump.c | 32 +++++++++++++++++++++++++++++++-
tools/hcidump.c | 33 +++++++++++++++++++++++++++++++--
2 files changed, 62 insertions(+), 3 deletions(-)
diff --git a/monitor/hcidump.c b/monitor/hcidump.c
index 8b6f846d3..6d2330287 100644
--- a/monitor/hcidump.c
+++ b/monitor/hcidump.c
@@ -107,6 +107,36 @@ static int open_hci_dev(uint16_t index)
return fd;
}
+static struct timeval hci_tstamp_read(void *data)
+{
+ struct timeval tv;
+
+ /*
+ * On 64-bit architectures, the data matches the timeval
+ * format. Note that on sparc64 this is different from
+ * all others.
+ */
+ if (sizeof(long) == 8) {
+ memcpy(&tv, data, sizeof(tv));
+ }
+
+ /*
+ * On 32-bit architectures, the timeval definition may
+ * use 32-bit or 64-bit members depending on the C
+ * library and architecture.
+ * The cmsg data however always contains a pair of
+ * 32-bit values. Interpret as unsigned to make it work
+ * past y2038.
+ */
+ if (sizeof(long) == 4) {
+ unsigned int *stamp = data;
+ tv.tv_sec = stamp[0];
+ tv.tv_usec = stamp[1];
+ }
+
+ return tv;
+}
+
static void device_callback(int fd, uint32_t events, void *user_data)
{
struct hcidump_data *data = user_data;
@@ -150,7 +180,7 @@ static void device_callback(int fd, uint32_t events, void *user_data)
memcpy(&dir, CMSG_DATA(cmsg), sizeof(dir));
break;
case HCI_CMSG_TSTAMP:
- memcpy(&ctv, CMSG_DATA(cmsg), sizeof(ctv));
+ ctv = hci_tstamp_read(CMSG_DATA(cmsg));
tv = &ctv;
break;
}
diff --git a/tools/hcidump.c b/tools/hcidump.c
index 33d429b6c..be14d0930 100644
--- a/tools/hcidump.c
+++ b/tools/hcidump.c
@@ -136,6 +136,36 @@ static inline int write_n(int fd, char *buf, int len)
return t;
}
+static struct timeval hci_tstamp_read(void *data)
+{
+ struct timeval tv;
+
+ /*
+ * On 64-bit architectures, the data matches the timeval
+ * format. Note that on sparc64 this is different from
+ * all others.
+ */
+ if (sizeof(long) == 8) {
+ memcpy(&tv, data, sizeof(tv));
+ }
+
+ /*
+ * On 32-bit architectures, the timeval definition may
+ * use 32-bit or 64-bit members depending on the C
+ * library and architecture.
+ * The cmsg data however always contains a pair of
+ * 32-bit values. Interpret as unsigned to make it work
+ * past y2038.
+ */
+ if (sizeof(long) == 4) {
+ unsigned int *stamp = data;
+ tv.tv_sec = stamp[0];
+ tv.tv_usec = stamp[1];
+ }
+
+ return tv;
+}
+
static int process_frames(int dev, int sock, int fd, unsigned long flags)
{
struct cmsghdr *cmsg;
@@ -230,8 +260,7 @@ static int process_frames(int dev, int sock, int fd, unsigned long flags)
frm.in = (uint8_t) dir;
break;
case HCI_CMSG_TSTAMP:
- memcpy(&frm.ts, CMSG_DATA(cmsg),
- sizeof(struct timeval));
+ frm.ts = hci_tstamp_read(CMSG_DATA(cmsg));
break;
}
cmsg = CMSG_NXTHDR(&msg, cmsg);
--
2.20.0
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.
The interface was originally added back in 2002 by Maksim Krasnyanskiy
when bluetooth support first became non-experimental.
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.
Fixing this the same was as normal socket timestamps is not possible
because include/net/bluetooth/hci.h is not an exported UAPI header.
This means any changes to it for defining HCI_TIME_STAMP conditionally
would be ignored by applications that use a different copy of the
header.
I can see three possible ways forward:
1. move include/net/bluetooth/hci.h to include/uapi/, add a conditional
definition of HCI_TIME_STAMP and make the kernel code support
both formats. Then change applications to rely on that version of
header file to get the correct definition but not change application code.
2. Leave the kernel completely unchanged and modify only the users
to not expect the output to be a 'struct timeval' but interpret as
as { uint32_t tv_sec; int32_t tv_usec; } structure on 32-bit architectures,
which will work until the unsigned time overflows 86 years from now
in 2106 (same as the libpcap on-disk format).
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.
Arnd
Hi Andrew,
Can you add these to your patches for linux-5.6?
I have y2038 cleanups for sound, v4l, nfsd, scsi and xfs that are
merged in the respective subsystem trees, as well as another
series of individual patches queued up in my own y2038 tree.
With all that work merged, most of include/linux/time32.h
and some other related code can be removed from the kernel,
so it would be good to send these at the end of the coming
merge window, and to give them some more testing in linux-next
to make sure we don't gain any new users.
Arnd
Arnd Bergmann (3):
y2038: remove ktime to/from timespec/timeval conversion
y2038: remove unused time32 interfaces
y2038: hide timeval/timespec/itimerval/itimerspec types
include/linux/compat.h | 29 -----
include/linux/ktime.h | 37 ------
include/linux/time32.h | 154 +------------------------
include/linux/timekeeping32.h | 32 -----
include/linux/types.h | 5 -
include/uapi/asm-generic/posix_types.h | 2 +
include/uapi/linux/time.h | 22 ++--
kernel/compat.c | 64 ----------
kernel/time/time.c | 43 -------
9 files changed, 15 insertions(+), 373 deletions(-)
--
Cc: y2038(a)lists.linaro.org
Cc: linux-kernel(a)vger.kernel.org
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Deepa Dinamani <deepa.kernel(a)gmail.com>
2.20.0
