Re: [PATCH] Y2038: provide kernel support indication

On Wed, Dec 5, 2018 at 2:48 PM Joseph Myers [off-list ref] wrote:

On Wed, 5 Dec 2018, Arnd Bergmann wrote:

quoted

I think it's important that we only do this when we are called from
an application with 64-bit time_t: When a user calls gettimeofday()
with 64-bit time_t, that should try clock_gettime64(2) and fall back
to clock_gettime(2) or gettimeofday(2) if that is unavailable. However
an application using gettimeofday() with a 32-bit time_t should
directly call gettimeofday(2) in the kernel but not try clock_gettime64()
first. Without that distinction, the kernel cannot return -ENOSYS
if we configure it to break compatibility with 32-bit time_t interfaces
and the application might seem to work correctly despite being
broken in 2038.

By design, all nontrivial 32-bit time interfaces in glibc for 32-bit
architectures should end up as simple wrappers round the implementations
using 64-bit time internally, to avoid duplication of complicated code
(previous versions of the Y2038 patches e.g. duplicated hundreds of lines
of pthread_mutex_timedlock implementation, which is clearly not a
maintainable approach).  That means many 32-bit interfaces *will* end up
using 64-bit syscalls (with fallback to 32-bit if the 64-bit syscalls are
unavailable at runtime), even if some simple functions that really are
just one syscall for 32-bit still call the old syscall.

That would make it very hard to deploy a glibc based system
with strict y2038 requirements. If we can no longer guarantee the
basic assumption that old applications keep using the old system
calls, then I think we instead need a way to build glibc itself without
support for the 32-bit time_t interfaces, e.g. using a --disable-time32
configuration switch to force a link-time error for any application
or library that has not been built against the 64-bit time_t interfaces.

The default would of course remain providing backwards compatibility
with all applications to allow a gradual migration from 32-bit time_t
to 64-bit time_t. If all 32-bit time_t calls are just wrappers around
either the internal implementation using 64-bit time_t or around
a simple system call, then it should at least be easy to make them
optional for users that need them not work.

Would that be something you can do?

      Arnd