Re: [klibc] kernel/libc uapi changes for y2038

On Monday 18 May 2015 17:03:08 Thorsten Glaser wrote:

quoted

MIPS on the other hand is no more broken than any of the other 32-bit
ABIs, because it does not use 64-bit __kernel_long_t in its n32 ABI.

I have heard from a MIPS porter that one of the flavours suffers
from similar problems as x32, just not to that extent. But I
don’t recall my source…

MIPS n32 has a lot of the same issues as x86 x32, but I'm pretty
sure that the time_t one is not among them.

quoted

ioctls. My plan at this point is to eliminate all uses of time_t in
the kernel and replace them with time64_t or other safe types.
This way, we will eventually find all code that passes 32-bit time types
to user space and can fix it. This will take care of the time_t
related problems on x32 as well.

Ah, interesting approach. And existing userspace, as well as new
userspace that does not declare 64-bit time_t readiness, is still
safe on currently-not-broken architectures? So, there’s enough time
to fix this before the various libcs turn that on (and it had better
be fixed by then, because it becomes ABI by then). Nice idea.

Correct. Another aspect of the approach I'm taking is that the
system-call implementation is shared between the native 64-bit
case and the new 32-bit case, while the handling for the existing
syscalls on 32-bit architectures is shared with the 32-bit compat
code on 64-bit architectures. This means if we introduce a bug
in either of them, we will find out very quickly and don't have
to wait until people start using 64-bit time_t on 32-bit user land.

I am wondering a bit about the ioctls being hard to find. I have
not much experience with kernel programming, and even less with
Linux than with MS-DOS and BSD, but should not each driver have
a central ioctl entry point, from which it should cast the user
space data into a (possibly locally declared) structure?

Yes, that's how it works, but unfortunately we have a few thousand
drivers that declare an ioctl function, and I hope to do something
better than brute-force search all of them. The other point is that
we really need to fix all y2038-related bug in drivers, not just
the ones in ioctl. This includes things like file systems storing
time in 32-bit units on disk, or drivers trying to measure how much
time has elapsed without communicating that value elsewhere, but
failing when the time_t number goes negative.

	Arnd
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038