From owner-freebsd-bugs@FreeBSD.ORG Mon Mar 7 21:21:07 2005 Return-Path: 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 E29F016A4CE; Mon, 7 Mar 2005 21:21:06 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32CE843D31; Mon, 7 Mar 2005 21:21:06 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j27LL4Hn019080; Tue, 8 Mar 2005 08:21:04 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j27LL1S5032473; Tue, 8 Mar 2005 08:21:02 +1100 Date: Tue, 8 Mar 2005 08:21:01 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Matthew Soffen In-Reply-To: <200503071549.j27Fnq14070462@www.freebsd.org> Message-ID: <20050308072635.G42370@delplex.bde.org> References: <200503071549.j27Fnq14070462@www.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-bugs@FreeBSD.org cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: misc/78537: times(2) not functioning per the Posix spec X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 21:21:07 -0000 On Mon, 7 Mar 2005, Matthew Soffen wrote: >> Description: > This is a finding from the Linux-Ha project and Robert Watson agrees that it does appear to be a bug in the behavior. > > According to the posix spec, the times (2) structure is supposed be unchangable from boot to boot. It is affected by any clock changes and per the spec ( http://www.opengroup.org/onlinepubs/009695399/functions/times.html ) it shouldn't be. Please limit line lengths to considerably less than 241 characters. I think you mean uniqueness of the returned value, not "unchangable from boot to boot" of the struct contents or the returned value. POSIX doesn't require any of these. It explicitly allows overflow of the returned value and implictly allows overflow of the struct contents, as in must since this interface is broken as designed and overflow occurs on most systems. >> How-To-Repeat: > Have something using a times(2) structure to generate unique ID ( for the current run), cange the system time and you would be able to create duplicate time structurs. times(2) cannot be used to generate unique ids, for many reasons: 1. The return value might overflow. It overflows in practice every 388+ days under FreeBSD. 2. The return value shouldn't be, but is under FreeBSD, non-monotonically increasing. This might be the bug that you mean. The return value should track a monotonic clock, one that is actually useful like CLOCK_MONOTONIC, but it actually tracks CLOCK_REALTIME. This is not a serious bug. Much more than times(2) breaks if CLOCK_REALTIME is allowed to to go backwards. 3. The return value might be non-strictly monotonic. Since the resolution of clock_t is too small to be useful for almost everything (still 1/128 seconds despite hat resolution being too small to be useful 10+ years ago when meachines were 1000+ times slower), the return vaue of times(2) is very likely to be the same for successive calls. 4. The return value might be non-unique across processes, even on non-SMP systems with processes making strictly ordered calls to times(), since POSIX permits even the return value to be relative to the start of the process so as to reduce the overflow possibilities for the return value. 5. The values in the struct might overflow. Under FreeBSD, this can happen after 388+ days for a process using 100% of the CPU. 6. The values in the struct might be non-monotically increasing. This isn't a problem under FreeBSD, but was on old versions until 1999/03/13. 7. The values in the struct might be non-strictly monotonic. This is the usual case in FreeBSD, as in (3). 8. The values in the struct might are non-unique across processes. >> Fix: > Make times(2) work like the posix spec. It shouldn't be based on Epoch being 0, it should be based on "startup" time being the 0 time. Basing it on the Epoch is not a problem, since overflow of clock_t is benign and the resulting timestamps are no less usable than ones based on a more recent starting point (in fact, they are more usable since you can determine the amount lost to overflow using a non-broken interface). POSIX doesn't require any particular starting point. As mentioned in (4), POSIX even allows using the start of the process for the starting point. Basing it on the Epoch is harder to implement since we only have monotonic times relative to system boot. Bruce