y2038 breakdown

Jan Kiszka jan.kiszka at siemens.com
Tue Sep 15 13:26:01 CEST 2020


On 15.09.20 09:05, song wrote:
> Hi guys,
> 
> After going through Arnd Bergmann's patch 
> list(https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=y2038-syscalls), 
> i'm going to get started at 64bit-xenomai y2038-safe(#1 in below list).
> 
> 1, timespec to __kernel_timespec in syscalls
>     timespec to timespec64
> 2, timex to __kernel_timex
> 3, syscalls, probably make a new one for 64bits and keep the old one for 
> compatibility (like clock_gettime, nanosleep...)
> 4, 2038-unsafe points in scheduler if there is (like sched time 
> interval..., i found xntimer is 64bit, which means it's 2038-safe)

Yeah, I don't think we have internal issues, "just" on the interfaces.

> 5, get_timespec to get_timespec64
>     timespec_valid to timespec64_valid
> 6, ktime_get_real to ktime_get_real_ts64
> 
> There would be more, i haven't figured out the whole pictures yet, and i 
> even haven't figured out how to make 32bit app 2038-safe either in 64bit 
> kernel or 32bit kernel, as far as my test, time goes back to 1901 when 
> sec is wrapped around in GPOS(5.4.40).

Existing apps using 32-bit types can't be made 2038-safe. It takes at 
least a recompilation so that they start using the new syscalls and also 
the new, widened data structures.

> 
> 1) root at kylin-Lenovo:/home/kylin/workspace/test-2038# ./test2038-gcc-32bit
> 1, Local time is: Tue Jan 19 11:13:40 2038
> 2, Local time is: Tue Jan 19 11:13:50 2038
> diff 10, sec 0x7fffffee
> 
> 1, Local time is: Tue Jan 19 11:13:50 2038
> 2, Local time is: Tue Jan 19 11:14:00 2038
> diff 10, sec 0x7ffffff8
> 
> 1, Local time is: Tue Jan 19 11:14:00 2038
> 2, Local time is: Sat Dec 14 04:45:54 1901
> diff 10, sec 0x80000002
> 
> 
> But things are getting clearer, if you have no problem with that, i will 
> start some small patches for review.
> 

That would be great! Make some basic test case one of the first patches 
so that we keep an eye on the effect, in all variants.

I've CC'ed you also in the dovetail thread, just to make you aware of 
Philippe's comments related to y2038 there.

Thanks,
Jan

> Let me know your thought about it, many thanks.
> 
> BR
> 
> chensong
> 
> 
> 
> On 2020/9/4 下午5:38, chensong via Xenomai wrote:
>> hi Henning,
>>
>> I collected some discussions about y2038 from upstream and made a
>> rough list for xenomai:
>>
>> 1, 64bit-xenomai y2038-safe
>> 2, 32bit-xenomai y2038-safe
>> 3, 64bit-ipipe y2038-safe (arm64, x86_64)
>> 4, 32bit-ipipe y2038-safe (arm, x86)
>> 5, syscall (posix and all other skins)
>> 6, libc
>> 7, 32 bit app y2038-safe
>> 8, 64 bit app y2038-sage
>>
>> For #1 ~ #4 above , we take care of In-kernel correctness, all the
>> data structures time is relevant to are going to be changed to long
>> long.or any old time data structures used in either xenomai or 
>> ipipe(probably timespec to timespec64).
>>
>> For #5, we need to keep the old syscalls for compatibility and
>> introduce new 64 bit syscalls.More specificlly, to create new 64bit
>> time_t/timespec/timeval/etc variants for syscalls, while
>> preserving existing interfaces(posix and all other skins).
>>
>> #6, do we need to care about it or we can benefit from upstream?
>>
>> #7, we need to cooperate with app developers and #8 seems to be safe
>> already.
>>
>>
>> other communities info :
>> NetBSD preserved compatibility with 2038 unsafe applications
>> OpenBSD did not (seeing the certainty of excluding unsafe
>> applications as a feature over compatibility)
>>
>>
>> http://lkml.iu.edu/hypermail/linux/kernel/1408.1/02587.html
>>
>> I will continue to work on the test case and start figuring out 32bit
>> time data structures in xenomai, how does it sound to you.
>>
>> BR
>>
>> chensong
>>
>>
>>
>>
> 
> 

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux



More information about the Xenomai mailing list