This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define
On Wed, Sep 04, 2019 at 06:53:54PM +0200, Florian Weimer wrote:
> * Joseph Myers:
> > On Wed, 4 Sep 2019, Florian Weimer wrote:
> >> * Lukasz Majewski:
> >> > There was also a conclusion regarding explicit clearing of the padding
> >> > if necessary - kernel shall do it (or to be more precise - kernel will
> >> > perform modulo operation of the number passed to it from glibc if
> >> > needed).
> >> But that's not what the kernel ended up doing, right?
> > My understanding is that it did - except for the case of compat syscalls
> > under 64-bit kernels 5.1.0 through 5.1.4.
> Then I don't quite get why we are having this conversation at all. The
> anonymous bit-field hack should solve this quite nicely if we just say
> that the exceptional range of kernels you indicated is too buggy to
> support in glibc.
> What am I missing?
I think you misunderstood my mail you were replying to in Message-ID
<firstname.lastname@example.org>. I was offering an easy way
(that was actually incorrect) to do the fixup to safely support
kernels 5.1.0-5.1.4. The motivation for doing so is as follows:
Normally, every now and then there's a range of kernel versions that
have a serious bug, and everybody quickly determines that they're not
usable. However for these versions, the "bug" doesn't affect any
existing 32-bit time32 software or 64-bit software, so it's plausible
that they'll stick around for a long time (as long as software built
with _TIME_BITS=64 is rare or nonexistent). Then, when someone
upgrades userspace (possibly even in a container, unrelated to the
host distro providing the bad kernel), everything will break
catastrophically, immediately 'timing out' with EINVAL or spinning at
It may be that glibc just doesn't want to bother with supporting this.
I wouldn't blame you for taking that position. For musl, it allowed
unifying the x32 padding code paths, which were previously horrible
hacks, with the new general code for time64-on-32, which was already
motivation enough, and getting safety on 5.1.0-5.1.4 is a nice bonus.