From: george anzinger <george@mvista.com>
To: "B. D. Elliott" <bde@nwlink.com>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@digeo.com>
Subject: Re: Sparc64-2.5.72: A Serious Time Problem
Date: Wed, 18 Jun 2003 02:12:39 -0700 [thread overview]
Message-ID: <3EF02D07.6000108@mvista.com> (raw)
In-Reply-To: <20030618073556.94E966A4FC@smtp4.pacifier.net>
B. D. Elliott wrote:
> There is a serious bug in setting time on 64-bit sparcs (and probably other
> 64-bit systems). The symptom is that ntpdate or date set the time back to
> 1969 or 1970. The underlying problems are that stime is broken, and any
> settimeofday call fails with a bad fractional value. Ntpdate falls back to
> stime when settimeofday fails.
>
> The settimeofday problem is that the timeval and timespec structures are not
> the same size. In particular, the fractional part is an int in timeval, and
> a long in timespec. The stime problem is that the argument is not an int,
> but a time_t, which is long on at least some 64-bit systems.
>
> The following patch appears to fix this on my sparc64.
Looks reasonable. The stime problem must have been there for some
time but I just introduced the timespec/ timeval thing. Someday soon
I will get this 64-bit long/int thing down. I promise :)
-g
>
> ===================================================================
> --- ./kernel/time.c.orig 2003-06-16 22:36:04.000000000 -0700
> +++ ./kernel/time.c 2003-06-18 00:00:43.000000000 -0700
> @@ -66,7 +66,7 @@
> * architectures that need it).
> */
>
> -asmlinkage long sys_stime(int * tptr)
> +asmlinkage long sys_stime(time_t * tptr)
> {
> struct timespec tv;
>
> @@ -162,13 +162,15 @@
>
> asmlinkage long sys_settimeofday(struct timeval __user *tv, struct timezone __user *tz)
> {
> + struct timeval user_tv;
> struct timespec new_tv;
> struct timezone new_tz;
>
> if (tv) {
> - if (copy_from_user(&new_tv, tv, sizeof(*tv)))
> + if (copy_from_user(&user_tv, tv, sizeof(*tv)))
> return -EFAULT;
> - new_tv.tv_nsec *= NSEC_PER_USEC;
> + new_tv.tv_sec = user_tv.tv_sec;
> + new_tv.tv_nsec = user_tv.tv_usec * NSEC_PER_USEC;
> }
> if (tz) {
> if (copy_from_user(&new_tz, tz, sizeof(*tz)))
> ===================================================================
>
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
prev parent reply other threads:[~2003-06-18 9:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-18 7:57 Sparc64-2.5.72: A Serious Time Problem B. D. Elliott
2003-06-18 9:12 ` george anzinger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3EF02D07.6000108@mvista.com \
--to=george@mvista.com \
--cc=akpm@digeo.com \
--cc=bde@nwlink.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.