Sparc64-2.5.72: A Serious Time Problem

Sparc64-2.5.72: A Serious Time Problem

[B. D. Elliott]

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.

===================================================================
--- ./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)))
===================================================================

-- 
B. D. Elliott   bde@nwlink.com

Re: Sparc64-2.5.72: A Serious Time Problem

[george anzinger]

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