Re: Accelerating Y2038 glibc fixes

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 18/07/2019 12:46, Rich Felker wrote:
> 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.
> 

This is BZ#18231 and I started to work on this some time ago. The main
issue is not really fix it, but consolidate all the implementations to
use a generic header for msg.h, sem.h, and shm.h, while providing 
compat symbol if it were the case.  I will try to check this out again,
since eventually I think we will need to get back to avoid a complicate
support for time64.