Date: Wed, 9 May 2001 23:30:09 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: dwmalone@FreeBSD.ORG Cc: freebsd-bugs@FreeBSD.ORG, des@FreeBSD.ORG Subject: Re: kern/27215: when cat'ing /compat/linux/proc/stat, we have negative numbers Message-ID: <Pine.BSF.4.21.0105092239510.18209-100000@besplex.bde.org> In-Reply-To: <200105091018.f49AI4X55752@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 9 May 2001 dwmalone@FreeBSD.ORG wrote: > Synopsis: when cat'ing /compat/linux/proc/stat, we have negative numbers > > Responsible-Changed-From-To: freebsd-bugs->des > Responsible-Changed-By: dwmalone > Responsible-Changed-When: Wed May 9 03:16:06 PDT 2001 > Responsible-Changed-Why: > Linprocfs is DES's. The patch looks straightforward though. It mainly obscures the bug, by moving obvious overflow after LONG_MAX/100 statclock ticks to unobvious overflow after ULONG_MAX/100 statclock ticks. Overflow thresholds for some cases: i386, stathz = 128: before: 1.94 days; after : 3.88 days alpha, stathz = 1024: before: 2.85 million years; after: 5.71 million years BTW, cp_time[x] has a stupid type. We use uint64_t to count ticks for individual processes (p_[uis]ticks in struct proc) but we still use "long" for cp_time[x]. Thus the tick counters for system times may overflow after 194 days on i386's with the default stathz, but the tick counters for individual processes don't overflow for 571 million years on the same system. However, calcru() doesn't actually work for 64-bit tick counters, so getrusage(2) breaks down for processes that have run for more than about 388 days. This overflow has actually been reported. See PR17482. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0105092239510.18209-100000>