=?ISO-8859-1?Q?RFD:_use_of_`xtime=B4_in_2.2.1_and_nanoseconds?=

Ulrich Windl (ulrich.windl@rz.uni-regensburg.de)
Thu, 25 Feb 1999 09:05:32 +0100


Hello,

going to nanoseconds needed some more fixes in kernel code. I'll
present some fixes here where kernel code directly accessed `xtimeŽ
and not one of the interface routines.

Many parts include <timex.h> or <sched.h> when they really wanted
<time.h> or <asm/timex.h>. With nanoseconds effective this will be
cleaned up.

fs/affs/file.c:

@@ -280,7 +280,7 @@
}
}
kc = NULL;
- tv = xtime;
+ get_exact_timeval(&tv);
for (i = 0; i < 4; i++) {
tkc = &inode->u.affs_i.i_ec->kc[i];
if (tkc->kc_lru_time.tv_sec > tv.tv_sec)
@@ -293,7 +293,7 @@
}
if (!kc) /* Really shouldn't happen */
kc = tkc;
- kc->kc_lru_time = xtime;
+ get_exact_timeval(&kc->kc_lru_time);
keyp = kc->kc_keys;
kc->kc_first = block;
kc->kc_last = -1;

Alternatively: do_gettimeofday(). I don't know whether 10ms
granularity would have been enough, but now you'd get the full
resolution. Possibly 10ms is a lot for filesystem operations...

fs/nfsd/nfssvc.c:

@@ -116,7 +116,7 @@
oldumask = current->fs->umask; /* Set umask to 0. */
current->fs->umask = 0;
if (!nfsd_active++)
- nfssvc_boot = xtime; /* record boot time */
+ get_exact_timeval(&nfssvc_boot); /* record
boot time */
lockd_up(); /* start lockd */

/*

Possibly the seconds would have been enough, but `xtime' is struct
timespec now, and not struct timeval...

net/ipv4/ip_forward.c:

@@ -97,7 +97,10 @@
#ifdef CONFIG_CPU_IS_SLOW
if (net_cpu_congestion > 1 && !(iph->tos&IPTOS_RELIABILITY) &&
IPTOS_PREC(iph->tos) < IPTOS_PREC_INTERNETCONTROL) {
- if (((xtime.tv_usec&0xF)<<net_cpu_congestion) > 0x1C)
+ /* If this is some random generator to drop packets
fairly,
+ * it's fine; otherwise fix it! -- UW
+ */
+ if (((xtime.tv_nsec & 0xF00) << net_cpu_congestion) >
0x1C00)
goto drop;
}
#endif

The original code is interesting, because on the i386 tv_usec starts
at 0 and is incremented by 10000 each timer interrupt. Thus "0 >
0x1c" is always false. In addition the network is much faster than
100Hz, probably having a need for a faster clock...
I don't know if my fix is correct, but it's here anyway.

net/sunrpc/svcauth_des.c:

@@ -175,10 +175,10 @@
#endif
}

- now = xtime;
+ do_gettimeofday(&now); /* now = xtime; need for speed? -- UW
*/
now.tv_secs -= data->dc_window;
if (now.tv_secs < cryptbuf[0] ||
- (now.tv_secs == cryptbuf[0] && now.tv_usec < cryptbuf[1]))
+ (now.tv_secs == cryptbuf[0] && now.tv_nsec / 1000 <
cryptbuf[1]))
FAIL(rejectedverf);

/* Okay, we're done. Update the lot */

The same thing here: Is 10ms resolution good enough, or do you really
need the speed? (You remember to use the lock before accessing xtime)

Regards,
Ulrich

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/