From owner-freebsd-bugs@FreeBSD.ORG Sun Jul 10 01:05:02 2005 Return-Path: X-Original-To: freebsd-bugs@FreeBSD.org Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA16B16A41C; Sun, 10 Jul 2005 01:05:02 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A03543D49; Sun, 10 Jul 2005 01:05:02 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j6A1503G021729; Sun, 10 Jul 2005 11:05:00 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j6A14xxX018766; Sun, 10 Jul 2005 11:04:59 +1000 Date: Sun, 10 Jul 2005 11:05:00 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Maciej Zawadzinski In-Reply-To: <200507091628.j69GS7rD070292@www.freebsd.org> Message-ID: <20050710104715.M1354@epsplex.bde.org> References: <200507091628.j69GS7rD070292@www.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-bugs@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/83192: X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2005 01:05:03 -0000 On Sat, 9 Jul 2005, Maciej Zawadzinski wrote: >> Fix: > --- kern_synch.c.orig Fri Jul 8 22:07:20 2005 > +++ kern_synch.c Fri Jul 8 22:07:47 2005 > @@ -322,7 +322,7 @@ > * over max, arrange to kill the process in ast(). > */ > if (p->p_cpulimit != RLIM_INFINITY && > - p->p_runtime.sec > p->p_cpulimit) { > + p->p_runtime.sec >= p->p_cpulimit) { > p->p_sflag |= PS_XCPU; > td->td_flags |= TDF_ASTPENDING; > } This seems to be correct, except it changes the code back to not matching the comment. p->p_cpulimit a max, not a limit despite its name, since it is an alias for the corresponding rlimit which is also a max, not a limit despite _its_ name. Doing something when a max is reached but not exceeded is normally wrong, but here we know that when the max in seconds is reached, the max in a significantly higher resolution is exceeded. The bug was smaller (< 1 usec, thus not observable) when it was originally implemented in rev.1.58 of kern_synch.c, since p_cpulimit was in microseconds then. Then the comparision of seconds still used ">=", but was only reached if the comparison of microseconds gave ">". Related bug: sys/resource.h says that RLIMIT_CPU gives the "cpu time in milliseconds", but it actually gives the _maximum_ CPU time in _seconds_. The man page and POSIX agree that it is in seconds but don't say if the comparison must or can be done at a higher resolution. Bruce