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

[Rich Felker <dalias at libc dot org>]

On Mon, Sep 09, 2019 at 03:19:50PM +0200, Florian Weimer wrote:
> * Rich Felker:
> 
> > 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.
> 
> I think it's better to break in catastrophic ways, making clear that the
> kernel is at fault, instead of expecting that application developers
> support kernels in the problematic range (probably without being able to
> test on them).  We could teach valgrind to optionally require the
> padding to be defined, but I'm not sure if that's very useful if there
> is software out there specifically written *not* to work on those
> problematic kernels (kind of like alignment traps on x86 are useless,
> now that software assumes that unaligned loads and stores are acceptable
> and have reasonable performance).

Requiring any action by application developers is not on the table;
that's contrary to the specification and a complete non-starter. The
question was whether glibc would support such kernels, which would not
be visible to the application.

Rich