Re: [PATCH] timekeeping: handle epoch roll-over (2038) on 32-bitsystems
From: John Stultz
Date: Mon Jun 03 2013 - 15:04:22 EST
On 06/03/2013 07:34 AM, Thomas Gleixner wrote:
B1;2601;0cOn Mon, 3 Jun 2013, Tobias Waldekranz wrote:
In ktime_get_update_offsets, calculate the current time in the sameIf we really want to survive 2038, then we need to get rid of the
way as in ktime_get.
On 32-bit systems, the current time is truncated via the call to
ktime_set, the following subtraction of offs_real will result in an
inaccurate time when the current number of seconds since epoch can no
longer fit in 31-bits (2038-01-19 03:14:07 UTC). This will send
hrtimer_interrupt into an infinite loop on some architectures (arm),
or emit an oops on others(x86).
timespec based representation of time in the kernel alltogether and
switch all related code over to a scalar nsec 64bit storage.
Just "fixing" some random parts of the code in a "make it work
somehow" way is a pointless exercise IMO.
We already had long discussions about how the timekeeping code should
be restructured to address that and other problems at least on the
kernel side and switching everything to scalar storage is definitely
the way to go.
Though even if we fix that we still need to twist our brains around
the timespec/timeval based user space interfaces. That's going to be
the way more interesting challenge.
So yea.. there's a couple approaches for userland that probably need
1) Create a new ABI for 32bit platforms that have a 64bit time_t
- I know x32 was talking about this, but I don't actually see that
code upstream, so maybe there was an issue that blocked this?
- In talking with some folks, there was some question on how to
handle multiple compat types, so a 64bit OS could support both old and
new 32bit abis. I suspect there's some approach that would work here,
but haven't done any research.
2) Add new time64_t/timespec64 structures, and add new 64bit versions of
syscalls for any syscall that takes a timespec/time_t
- This is a ton of work, and lots of new syscalls. Yuck.
3) Redefine time_t to be unsigned. (Possibly as part of an abi bump?).
This is attractive, as it requires the least change to the kernel
interfaces, and in many cases existing userland won't care (there' no
userland that's setting timers for dates prior to 1970). We'd just need
to update the libc ascii time formatting, and basically give up dates
prior to 1970. Of course, this is probably too optimistic as existing
userland code that does (time_a < time_b) would have issues comparing
dates before and after the 2038 overflow. However, those apps will be
broken no matter what, so I'm starting to think this approach is likely
to be the most reasonable.
I'm curious if there are any there other ideas that folks are considering?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/