[RFC 0/6] y2038: Prepare glibc to be Y2038 safe for 32 bit ports

[Lukasz Majewski]

Hi Joseph,

> On Sat, 5 Dec 2020, Lukasz Majewski wrote:
> 
> > This patch series is the RFC for preparing glibc to be Y2038 safe on
> > ports with __WORDSIZE=32 && __TIMESIZE!=64 (e.g. 32 bit ARM).  
> 
> What exactly does "preparing" mean here?

In this particular case - I meant that all the patches in this series
are necessary to provide Y2038 support. Please also be aware that this
is only the RFC.

To be more specific - only patch 1/6 will be the "transitional" patch
in a sense that after applying it the _TIME_BITS flag would be
introduced and ready to be use by users.

Patches following it - i.e. from 2 to 6 are added to show what is
needed to tune glibc to have 64 bit time support. Those are mostly
related to earlier 'stat' rework done by Adhemerval and shall be
applied (or the problem shall be resolved in the other way) before patch
1/6 is applied.

I just wanted to wrap all the necessary patches in a single patch
series to show how much work is still necessary.

> 
> I'd expect support for _TIME_BITS to go along with public symbol
> versions for all the new symbols that functions get redirected to,
> because otherwise people building with _TIME_BITS=64 will get either
> link failures or broken binaries depending on GLIBC_PRIVATE symbols.
> But as far as I can see, this patch series only adds GLIBC_PRIVATE
> symbols, not any public symbols or corresponding abilist updates.

You are right - this was my omission. I've added those new symbols to
GLIBC_PRIVATE as it was easier for maintenance.

For the "final" version of this patch set I will add all those symbols
to GLIBC_2.3X {}.

> 
> I'd also expect support for _TIME_BITS to go along with tests
> covering all the new interfaces (that is, for every time-affected
> interface, there should be a test that it works properly with
> _TIME_BITS=64, typically a test that defines _TIME_BITS to 64 then
> includes an existing test for that interface, possibly with other
> tests to verify that large time values work properly where possible).

This is a bit problematic as was discussed earlier [1] as we don't
have the easy way to set host's (on which tests are running) time.

The time namespaces don't support CLOCK_REALTIME, and the only feasible
way to do this is with re-using (and optimizing):
test-wrapper='/opt/glibc/src/scripts/cross-test-ssh.sh

I'm also concerned how this work shall be divided - the patch which
introduces _TIME_BITS flag would be very large and difficult to review.
Would it be allowed to add tests (which would use _TIME_BITS) to glibc
tree earlier?

> 
> You don't say how this series was tested,

This patch set causes following Y2038 tests being all passed:
https://github.com/lmajewski/y2038-tests/

Those tests are run as part of meta-y2038:
https://github.com/lmajewski/meta-y2038/

Those are "simple" programs to test single syscall (e.g. clock_settime
or stat) built with _TIME_BITS=64 and _FILE_OFFSET=64 and run on QEMU
(arm32 bit vexpress-c15 board).

This is the only way to be able to set future time after time_t
overflow.

> but this may be around the
> point where build-many-glibcs.py testing is needed. 

In the thread [2] - I've suggested such approach, but this would imply
setting/changing time on the build host.

To overcome this problem we would need time namespaces, but for now
there is no plan to provide such functionality ([1]).

> Certainly any
> patch in such a series that adds a new public symbol should be tested
> with build-many-glibcs.py to make sure that all the ABI test baseline
> updates are correct.
> 

Would it be possible to test e.g. clock_settime64 if it sets correct
time after 32 bit time_t overflow? Any other syscall would require time
adjustment of host to properly test execution paths.

Would you recommend extending build-many-glibc to also download, build
qemu and run tests inside?

In the discussion [1] it was pointed out that this would be a bit
cumbersome. 

Last but not least, just the "build" testing shall be provided with
current setup as for e.g. __WORDSIZE=32 and __TIMESIZE!=64 (e.g. arm32
bit) we do use 64 bit interfaces anyway.


Links:
[1] - https://lore.kernel.org/lkml/20201114102503.GB1000@bug/T/
[2] -
http://sourceware-org.1504.n7.nabble.com/Y2038-Question-about-porting-y2038-tests-to-glibc-td652557.html

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20201207/4adebff9/attachment.sig>