year 9223372034708485227 problem

year 9223372034708485227 problem

[Pavel Machek]

Hi!

For testing (read() and write() is returning wrong value on 2.4
kernels) I played a bit with really big numbers... And I found out we
have year 9223372034708485227 problem ;-).

hobit:/tmp # cat 2gbtime.c

/**************************** 2gbwrite.c **************************/
#define _SVID_SOURCE /* glibc2 needs this */
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <values.h>
#include <malloc.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
#include <time.h>

int main(int argc, char **argv)
{
  long t = 0x7fffffff80123456;
  stime(&t);
  printf("It is now: %lx\n", time(NULL));
}
/*********************** end of 2gbwrite.c *************************/
hobit:/tmp # ./2gbtime
It is now: 7fffffff80123456
hobit:/tmp # date
Segmentation fault
hobit:/tmp # top
Segmentation fault
hobit:/tmp # mc
Segmentation fault
hobit:/tmp # /sbin//shutdown -r now
Segmentation fault
hobit:/tmp # halt
Segmentation fault
hobit:/tmp #

I'm not sure if it is kernel problem... but it is sure pretty
common. I wonder how much damage it will do to my filesystems: touch
foo seems to store the right year into reiserfs. I wonder if it is
still there after reboot? No, it is not. That looks like kernel bug :-).

Anyway I believe we are going to have some fun in year 2038. Even if
all systems are 64-bit by then, there will still be some 32-bit fields
hidden somewhere.

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: year 2038 problem on x86-64

[Pavel Machek]

Hi!

> For testing (read() and write() is returning wrong value on 2.4
> kernels) I played a bit with really big numbers... And I found out we
> have year 9223372034708485227 problem ;-).

And we have some nearer problems, too.

#ifdef __ARCH_WANT_SYS_TIME

/*
 * sys_time() can be implemented in user-level using
 * sys_gettimeofday().  Is this for backwards compatibility?  If so,
 * why not move it into the appropriate arch directory (for those
 * architectures that need it).
 *
 * XXX This function is NOT 64-bit clean!
 */
asmlinkage long sys_time(int __user * tloc)
{
        int i;
        struct timeval tv;

        do_gettimeofday(&tv);
        i = tv.tv_sec;

        if (tloc) {
                if (put_user(i,tloc))
                        i = -EFAULT;
        }
        return i;
}

... __ARCH_WANT_SYS_TIME actually is set on x86-64.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: year 2038 problem on x86-64

[Andi Kleen]

Pavel Machek <pavel@ucw.cz> writes:
>
> ... __ARCH_WANT_SYS_TIME actually is set on x86-64.

But it's not used. It declares an own sys_time64 in arch/x86_64
By default the vsyscall code is used.

Also sys_time is legacy, most users should be using gettimeofday()

-Andi

Re: year 2038 problem on x86-64

[Pavel Machek]

Hi!

> >
> > ... __ARCH_WANT_SYS_TIME actually is set on x86-64.
> 
> But it's not used. It declares an own sys_time64 in arch/x86_64
> By default the vsyscall code is used.

So should __ARCH_WANT_SYS_TIME be  killed from x86_64?

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: year 2038 problem on x86-64

[Andi Kleen]

Pavel Machek <pavel@suse.cz> writes:

> Hi!
>
>> >
>> > ... __ARCH_WANT_SYS_TIME actually is set on x86-64.
>> 
>> But it's not used. It declares an own sys_time64 in arch/x86_64
>> By default the vsyscall code is used.
>
> So should __ARCH_WANT_SYS_TIME be  killed from x86_64?

No. The 32bit emulation uses it.

In theory you could make it conditional on CONFIG_IA32_EMULATION,
but that would be probably overkill.

-Andi