Re: Second draft of the Y2038 design document

[Arnd Bergmann <arnd at arndb dot de>]

On Thursday 28 January 2016 13:13:09 Paul Eggert wrote:
> Some typos: "1901-12-13 19:55:13 UTC" should be "1901-12-13 20:45:52 
> UTC". "sentive" should be "sensitive". "20338" should be "2038". "Thins" 
> should be "This".
> 
> I don't see why functions like 'time' and 'gettimeofday' should be 
> allowed to misbehave on 64-bit hosts after 2038. They should just work. 
> Glibc should not worry about 64-bit kernels without 64-bit time support. 
> Any such kernels should just get fixed before 2038 rolls around.
> 
> Why are struct rusage, getrusage, etc. Y2038-sensitive? They hold 
> intervals, not absolute times.

It can theoretically still overflow, though not at the same time:
If you have a large NUMA system with thousands of CPUs and an HPC
workload running on all of them for a couple of months at a time,
the field will overflow.

getrusage is also an example of a class of interfaces that need to
be addressed in one way or another because they contain a time_t
member in a structure, so any user space program that sees the
current definition of struct rusage but uses a 64-bit time_t will
disagree on the layout with the old kernel system call. Other
interfaces in this class are clock_getres, pselect, ppoll,
io_getevents, recvmmsg, semtimedop, rt_sigtimedwait,
sched_rr_get_interval, and sysinfo, along with many ioctl commands.
There is no overflow in them, but we have to either add a
replacement interface, or redefine the API to pass a 'long' instead
of 'time_t' to keep binary compatibility.

My current patch set for the kernel syscalls uses a structure
with all 64-bit members, so we can share the implementation between
the new 32-bit system call in compat mode with the existing native
64-bit system call. I'm not particularly attached to that solution,
it's just one of multiple ways to do this and I had to pick one.

	Arnd