Fwd: [musl] Re: musl getaddr info breakage on older kernels

[Satadru Pramanik <satadru@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2563 bytes --]

>
>
> > Getting a signed kernel update for an EOL kernel for an EOL machine is
> > close to impossible from Google, so we're just trying to work around
> these
>
> If these are machines you're in control of, you may be able to load a
> module to patch it. If this is something you're deploying to users
> stuck on that kernel who don't want to fix their systems, then of
> course that's not a practical option.
>
> Deploying kernel modules to EOL machines is probably not worth doing at
this point. One might argue this is just a pointless exercise in preserving
legacy technology!


> issues in userspace to maintain some functionality for any users who may
> > still be using the device.
> >
> > The simplest workaround possible would be ideal.
>
> If you're shipping binaries specifically for these devices, the
> simplest fix is just to emulate the failure that should happen in the
> kernel in userspace, using the attached patch. DO NOT deploy this
> patch in binaries meant to be used on modern systems, since they will
> break when Y2038 rolls around. (Your old Chromebooks will break then
> too.)
>
> I'll let the next generation of preservationists worry about the Y2038
issues. Thanks for the patch. I'll build that now with the
https://git.musl-libc.org/cgit/musl/patch/?id=c2feda4e2ea61f4da73f2f38b2be5e327a7d1a91
reversal patch for the i686 machines, and see if that fixes the issue. If
so, we can consider the matter closed, unless you want to suggest a
modification of the syscall patch to handle older working kernels which
might avoid the need for the patch when used with older systems.


> It is interesting though
> > that the sample program works fine when built against near-stock glibc
> > 2.23, no?
>
> No. If your kernel has a bug that makes something behave wildly wrong,
> whether you do or don't see that as visible breakage with a particular
> piece of software is not particularly interesting.
>
> I'm pretty sure, however, that you just haven't tested enough to see
> any failures. glibc 2.23 is from 2016, so any functionality in it
> using syscalls added after 2011 (3.8 kernel) is going to blow up
> badly, thinking the syscall succeeded and returned some positive value
> when actually the kernel lacks it.
>
> In the particular case of clock_gettime, it's just that your glibc
> 2.23 has a hard Y2038 EOL and does not use/support the missing time64
> syscalls.
>
>
Duly noted.

Thanks so much for being patient while I got you enough information to fix
this!

On behalf of the entire Chromebrew community, thank you!

Satadru

[-- Attachment #2: Type: text/html, Size: 3575 bytes --]