This is the mail archive of the
libc-alpha@sourceware.org
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.
>
> Oh!
>
> 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
<871rwwp7dm.fsf@oldenburg2.str.redhat.com>. 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
100% cpu.
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.
Rich