[Xenomai] Winter^W y2038 is coming

[Xenomai] Winter^W y2038 is coming

[Jan Kiszka]

Hi,

likely due to some platform oddities (still has to be analyzed in more
details), we are running into the situation that xntimer_grab_hardware
on a x86-64 host tunes nkclock.wallclock_offset to a value that is not
compatible with the 32-bit time_t ABI of compat applications. If you do
a pattern like

    abs_timeout = clock_gettime(CLOCK_REALTIME) + rel_timeout
    some_abs_wait(abs_timeout)

that abs_wait will practically wait forever. The same bug can also be
triggered by doing a

    clock_settime(CLOCK_REALTIME, -negative_date)

I'm now wondering if we should take measures that detect or even prevent
the setting of invalid dates in the presence of 32-bit ABIs. Or if we
should suggest/demand the setting of -D_TIME_BITS=64 already. The clock
is ticking... Thoughts?

Jan

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

Re: [Xenomai] Winter^W y2038 is coming

[Wolfgang Denk]

Dear Jan Kiszka,

In message <9d0a8dc6-d16d-e3e2-8d20-400e5e2e4b4c@siemens.com> you wrote:
> 
> I'm now wondering if we should take measures that detect or even prevent
> the setting of invalid dates in the presence of 32-bit ABIs. Or if we
> should suggest/demand the setting of -D_TIME_BITS=64 already. The clock
> is ticking... Thoughts?

As you well know, there are quite a few projects with product life
times of 20 years, so we really should start to raise awareness of
the y2038 problem.  In a case like this I think the best way is to
push forward for 64 bit time stamps.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it  on
the computer.

Re: [Xenomai] Winter^W y2038 is coming

[Philippe Gerum]

On 02/21/2018 07:33 PM, Jan Kiszka wrote:
> Hi,
> 
> likely due to some platform oddities (still has to be analyzed in more
> details), we are running into the situation that xntimer_grab_hardware
> on a x86-64 host tunes nkclock.wallclock_offset to a value that is not
> compatible with the 32-bit time_t ABI of compat applications. If you do
> a pattern like
> 
>     abs_timeout = clock_gettime(CLOCK_REALTIME) + rel_timeout
>     some_abs_wait(abs_timeout)
> 
> that abs_wait will practically wait forever. The same bug can also be
> triggered by doing a
> 
>     clock_settime(CLOCK_REALTIME, -negative_date)
> 
> I'm now wondering if we should take measures that detect or even prevent
> the setting of invalid dates in the presence of 32-bit ABIs. Or if we
> should suggest/demand the setting of -D_TIME_BITS=64 already. The clock
> is ticking... Thoughts?
> 

AFAIU, y2038 will hit any configuration showing timespec32 in the table
below:

CPU-bitness    	ABI		Timespec

64		native		timespec64
64		x32*		timespec64
64		ia32*		timespec32
32		native		timespec32

(*) x86 specific

To sum up, x86_64 applications using the ia32 ABI, and any application
running on a 32bit CPU won't make it after that date, with the current code.

Ignoring the case of 32bit platforms for which there does not seem to be
much of a hope in mainline anyway, I would favor option #2 for ia32
apps, i.e. assume that the underlying *libc can be told to pass
timespec64 arguments, and have the compat mode wrappers in Cobalt assume
userland always gives timespec64.

To make sure kernel & userland agree on the timespec bitness, we could
add a dedicated information bit to cobalt_bindreq::feat_req.

I believe that those updates should go to 3.1, since they induce ABI
changes, and it seems reasonable to ask ia32 ABI users to upgrade the
*libc (for getting the timespec64 switch) along with the real-time core
and libraries.

-- 
Philippe.