From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [PATCH] y2038: replace timespec with timespec64 in clock_settime References: <1600691577-12011-1-git-send-email-chensong@tj.kylinos.cn> <01014f7c-76ed-46ea-0c7c-920f6eb63b0e@siemens.com> <27465fc4-ab13-ffb7-eec4-21160fbeec8a@tj.kylinos.cn> <7e00b8e7-4029-00f0-38dc-6d9452b552e7@siemens.com> <5F72D3CF.7070200@tj.kylinos.cn> <8ab3d084-e9bc-de32-1095-403ac6e1a2c9@web.de> <5F8425BD.7090208@tj.kylinos.cn> From: chensong Message-ID: <5F8E9B65.2050202@tj.kylinos.cn>+F7E1B226D6718E94 Date: Tue, 20 Oct 2020 16:10:13 +0800 MIME-Version: 1.0 In-Reply-To: <5F8425BD.7090208@tj.kylinos.cn> Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka , xenomai@xenomai.org Hi Jan; i talked to arnd Bergmann about how to build a 32bit 2038-safe process, he told me that neither gcc nor glibc can fully support 64bit timespec yet, he suggested me to use musl(https://wiki.musl-libc.org/), and he also suggested me to use kernel5.4. I followed his suggestion, built a 32bit process with musl-gcc and ran it in a armv7l device, and it's working fine, safe. Then i turned to xenomai, it took a lot time to build libcobalt with musl's toolchain(https://musl.cc/), it worked anyway, but i found it called linux's clock_settime(kernel/time/posix-timers.c) instead of cobalt's clock_settime, i'm stuck here. what's more, to enable 64bit __kernel_timespec should enable CONFIG_64BIT_TIME, it's off by default, i turned it on but system can't bootup. Ideally, if we could verify a 32bit process 2038-safe in both 32bit system and 64bit system, we could continue to work on other syscalls, but now, what can we do? shall we create a new branch specific for y2038 which we can apply out patches on and mainline them after gcc/glibs is ready for verification? Let me know your opinion about this case, many thanks. BR chensong On 2020年10月12日 17:45, chensong wrote: > > > On 2020年10月01日 03:19, Jan Kiszka wrote: >> On 29.09.20 08:27, chensong wrote: >>> >>> >>> On 2020年09月29日 00:52, Jan Kiszka wrote: >>>> On 23.09.20 03:40, song wrote: >>>>> >>>>> >>>>> On 2020/9/22 下午11:16, Jan Kiszka wrote: >>>>>> On 21.09.20 14:32, chensong wrote: >>>>>>> Upstream has used timespec64 to replace timespec inside kernel and >>>>>>> used __kernel_timespec to replace timespect in syscalls, therefore >>>>>>> we must keep aligned with upstream. >>>>>>> >>>>>>> clock_settime is a point to get started at, it involves 2 parts: >>>>>>> 1, syscall in ./include/trace/events/cobalt-posix.h for 64bits >>>>>>> 2, compat syscall in kernel/cobalt/posix/syscall32.c for 32bits >>>>>>> >>>>>>> some new functions are implemented to keep the compatibility with >>>>>>> other syscalls which haven't been handled yet and will be removed >>>>>>> in the end of the work. >>>>>> >>>>>> So, this switches also existing syscalls to 64-bit types, breaking >>>>>> the >>>>>> current ABI, no? How much effort would it be to keep the old ABI, >>>>>> adding a 64-bit one aside of it? >>>>> >>>>> Not breaking current ABI, i didn't add any new ABIs specific for >>>>> 64bits, >>>>> i added some new static functions, like ts2ns and ts2ns64, >>>>> sys32_put_timespec and sys64_put_timespec, specific for clock_settime. >>>>> >>>> >>>> clock_settime accepts struct timespec so far, you are changing that to >>>> struct __kernel_timespec. If I look at its definition in the kernel, it >>>> uses __kernel_time64_t as tv_sec type. But our current 32-bit users >>>> still expects a 32-bit type here, no? Would that change already require >>>> a new clock_settime64 syscall if we wanted to stay binary compatible? >>> >>> 32 bit user space processes go to >>> COBALT_SYSCALL32emu(clock_settime,current,(clockid_t clock_id,const >>> struct compat_timespec __user *u_ts)) defined in >>> ./kernel/cobalt/posix/syscall32.c. It uses compat_timespec which 32it is >>> compatible with. >>> >>> I tested 32bit application and 64bit application on 64bit system >>> respeactively >>> 32bit process -- clock_settime -- COBALT_SYSCALL32emu(clock_settime >>> 64bit process -- clock_settime -- COBALT_SYSCALL(clock_settime) >>> >> >> You also need to consider 32-bit kernels, not on x86 anymore (i386 is >> practically dead), but e.g. ARMv7. There we would have a breakage now, >> don't we? >> > i tested 32bit process on a 32bit kernel (raspberry 2, armv7), it seems > timespec64 is working fine. > > If this patch is acceptable for you, i will start clock_gettime. > meanwhile, i will email Arnd Bergmann to see how to > enable 64bit timespec in userspace to see if 32bit process is 2038-safe > in both 32bit kernel and 64bit kernel. > >> Jan >>