From owner-freebsd-bugs@FreeBSD.ORG Sun Jul 10 01:10:23 2005 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1EB416A41C for ; Sun, 10 Jul 2005 01:10:23 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4BF843D46 for ; Sun, 10 Jul 2005 01:10:23 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j6A1ANi8089774 for ; Sun, 10 Jul 2005 01:10:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j6A1ANXr089773; Sun, 10 Jul 2005 01:10:23 GMT (envelope-from gnats) Date: Sun, 10 Jul 2005 01:10:23 GMT Message-Id: <200507100110.j6A1ANXr089773@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Bruce Evans Cc: Subject: Re: kern/83192: X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2005 01:10:23 -0000 The following reply was made to PR kern/83192; it has been noted by GNATS. From: Bruce Evans To: Maciej Zawadzinski Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/83192: Date: Sun, 10 Jul 2005 11:05:00 +1000 (EST) 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