Re: [PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define

[Rich Felker <dalias at libc dot org>]

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