Re: Accelerating Y2038 glibc fixes

[Rich Felker <dalias at libc dot org>]

On Thu, Jul 18, 2019 at 04:49:31PM +0200, Florian Weimer wrote:
> * Rich Felker:
> 
> > On Wed, Jul 17, 2019 at 11:57:48PM +0200, Lukasz Majewski wrote:
> >> Note:
> >> 
> >> [1] -
> >> https://github.com/lmajewski/y2038_glibc/commits/Y2038-2.29-glibc-11-03-2019
> >> 
> >> [2] - https://github.com/lmajewski/y2038-tests
> >> 
> >> [3] -
> >> https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?highlight=%28y2038%29
> >> 
> >> [4] - https://github.com/lmajewski/meta-y2038/tree/master
> >
> > Some findings here that need correction:
> >
> > [1] is completely missing the sysvipc interfaces affected, and [3]
> > fails to document them as affected because the structs are variadic
> > arguments not declared ones. Fortunately, this means we can get away
> > without actually replacing the functions, and instead define new
> > command numbers to perform the translation. When doing this, glibc
> > should follow musl and correct other bugs in these structs: for
> > example, struct ipc_perm's mode field has the wrong type on some archs
> > (short instead of mode_t; only makes a difference on big endian).
> 
> Do the musl types match the kernel types?

Largely, since the kernel also left padding, but in the wrong order
for big endian. So instead of short+padding for mode on affected
archs, we have mode_t mode. On big endian variants of these archs,
this requires some fixup code to swap the upper/lower 16 bits.

With time64, if you're bothering to decode the extra time bits (on
most archs these are in adjacent padding and just need endian swapping
on big endian; on some archs they're in non-adjacent padding) already
then it's no big deal to fix the mode_t at the same time.

Note that on most archs, fixing these structs for time64 is just
replacing the 32-bit time_t and adjacent padding with a 64-bit time_t.
But on the exceptions (probably mips, because eew..) the struct needs
more significant changes.

Rich