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

[Florian Weimer <fweimer at redhat dot com>]

* 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).

Thanks,
Florian