From owner-freebsd-current Fri Aug 21 16:50:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA15621 for freebsd-current-outgoing; Fri, 21 Aug 1998 16:50:38 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from zone.syracuse.net (zone.syracuse.net [205.232.47.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA15610 for ; Fri, 21 Aug 1998 16:50:36 -0700 (PDT) (envelope-from green@unixhelp.org) Received: from localhost (green@localhost) by zone.syracuse.net (8.8.8/8.8.7) with SMTP id TAA24470; Fri, 21 Aug 1998 19:49:35 -0400 (EDT) Date: Fri, 21 Aug 1998 19:49:34 -0400 (EDT) From: Brian Feldman X-Sender: green@zone.syracuse.net To: Stefan Eggers cc: freebsd-current@FreeBSD.ORG Subject: Re: 13 months of user time? In-Reply-To: <199808210836.KAA02477@semyam.dinoco.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Argh, you're right, I entirely forgot about having to handle the microsecond counter, that it's not like seconds since the epoch, and rolls over all the time ;) But in all these cases, it's a BIG change, so tv_usec shouldn't matter at all anyway, so the following should do: if (switchtime.tv_sec < p->p_switchtime.tv_sec) panic("%s at line %d: time check failed, time going backwards", __FILE__, __LINE__); Cheers, Brian Feldman On Fri, 21 Aug 1998, Stefan Eggers wrote: > > SIGXCPU kill problem could try putting the following in kern/kern_synch.c > > line 638: > > I think better not this one as that is a safe way to a panic IMHO. A > version I think does what you intend this to do I add below. It is > untested code I just added while writing the mail. > > > if (switchtime.tv_usec < p->p_switchtime.tv_usec || > > switchtime.tv_sec < p->p_switchtime.tv_sec) > > panic("bogus microuptime twiddling"); > > > > And see if we get some nice panics and cores. Is it worth a shot? I've > > As far as I can see the timeval in the process structure is a real > timeval and not abused to be something else. So tv_usec contains the > micro seconds part and tv_sec the seconds. > > Let's assume that p->p_switchtime.tv_usec contains 999999 now and > p->p_switchtime.tv_sec is 0. Lets suppose the time continues a little > bit and when we reach the if statement switchtime.tv_usec might > contain 0 and switchtime.tv_sec 1. The time didn't go backward but > with the code above causes a panic. > > > never gotten a SIGXCPU out of place, so my machine wouldn't be the one to > > test this on. > > And I don't think you want the test this way, anyway. ;-) > > One has first to calculate a 64 bit integer from the seconds and micro > seconds and then compare the two resulting numbers. With that it > could actually detect switchtime going backward. > > Something like this: > > int64_t time1, time2; > [...] > time1 = switchtime.tv_usec + switchtime.tv_sec * (int64_t)1000000; > time2 = p->p_switchtime.tv_usec + p->p_switchtime.tv_sec * (int64_t)1000000; > if (time1 < time2) > panic("Ooops! Switchtime going backward!"); > > Stefan. > -- > Stefan Eggers Lu4 yao2 zhi1 ma3 li4, > Max-Slevogt-Str. 1 ri4 jiu3 jian4 ren2 xin1. > 51109 Koeln > Federal Republic of Germany > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message