From owner-freebsd-arch@FreeBSD.ORG Wed Dec 19 15:58:15 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2386FDA1; Wed, 19 Dec 2012 15:58:15 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) by mx1.freebsd.org (Postfix) with ESMTP id 8F2BE8FC13; Wed, 19 Dec 2012 15:58:14 +0000 (UTC) Received: by mail-vb0-f53.google.com with SMTP id b23so2410492vbz.26 for ; Wed, 19 Dec 2012 07:58:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MZwBLAXR5ZQuT6zg0qGkR7r8/PYRwl3fCa5jYWpUoE8=; b=Zrlkhba+OFc6g/mdMC4zHJFh+hTCQV0Vzfxru89bbZy8R6SCg9JrC9Xss2XQMUPqF+ 4o9E/wAMDk0RrkssIWvc7bC1YwOTwAJPwAzcocSmwia46cwbsYC2LfbEfOAu2+uVL8+E 0Xa5O8vivrtuoFb0m6RB1jkvjdvMFQieRJGNyPELZOYctSoerbhiCnwbxDxbrIgyqVOd feJShTg6A5wePTT+mhWzsnu0chfnAw7fOsPAVMwclgLvucOI6s54SY08V2iNMZxt2wJr oFR7eNI+fhHQYT2OJDcjvfceUqzC0emGeIOPeYUbMByFVxdDVgnxnB4/yjsIV2PKRguh IHIg== MIME-Version: 1.0 Received: by 10.220.148.205 with SMTP id q13mr9184719vcv.6.1355928707925; Wed, 19 Dec 2012 06:51:47 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.58.229.136 with HTTP; Wed, 19 Dec 2012 06:51:47 -0800 (PST) In-Reply-To: <20121220010702.B1675@besplex.bde.org> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <15882.1355914308@critter.freebsd.dk> <20121219221518.E1082@besplex.bde.org> <20121220010702.B1675@besplex.bde.org> Date: Wed, 19 Dec 2012 06:51:47 -0800 X-Google-Sender-Auth: spBVXsoWBq0qXz79KesqcXmg_C8 Message-ID: Subject: Re: API explosion (Re: [RFC/RFT] calloutng) From: Davide Italiano To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: Ian Lepore , Poul-Henning Kamp , freebsd-current , Alexander Motin , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:58:15 -0000 dropping phk _AT_ onelab2 _DOT_ something from CC as long as it doesn't seem a valid mail address and I'm annoyed mails bounce back. On Wed, Dec 19, 2012 at 6:20 AM, Bruce Evans wrote: > On Wed, 19 Dec 2012, Davide Italiano wrote: > >> On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans wrote: > > >>> I would have tried a 32 bit format with a variable named 'ticks'. >>> Something like: >>> - ticks >= 0. Same meaning as now. No changes in ABIs or APIs to use >>> this. The tick period would be constant but for virtual ticks and >>> not too small. hz = 1000 now makes the period too small, and not a >>> power of 2. So make the period 1/128 second. This gives a 1.24.7 >>> binary format. 2**24 seconds is 194 days. >>> - ticks < 0. The 31 value bits are now a cookie (descriptor) referring >>> to a bintime or whatever. This case should rarely be used. I don't >>> like it that a tickless kernel, which is needed mainly for power >>> saving, has expanded into complications to support short timeouts >>> which should rarely be used. >> >> >> Bruce, I don't really agree with this. >> The data addressed by cookie should be still stored somewhere, and KBI >> will result broken. This, indeed, is not real problem as long as >> current calloutng code heavily breaks KBI, but if that was your point, >> I don't see how your proposed change could help. > > > In the old API, it is an error to pass ticks < 0, so only broken old > callers are affected. Of course, if there are any then it would be > hard to detect their garbage cookies. > > Anywy, it's too later to change to this, and maybe also to a 32.32 > format. > > [32.32 format] It's not too late. What I'd like to do, right now people got interested in the problem is agreeing on the interface used. Following this thread, as I've already discussed to mav@, we would like to decide what of the two is better: - specify precision as additional argument (as we're doing right now) - use 'flags' argument If we allow time argument to be relative and not absolute, as suggested by luigi@, we can easily use relative precision where we had to use ffl() before. >>> >>> This would make a better general format than timevals, timespecs and >>> of course bintimes :-). It is a bit wasteful for timeouts since >>> its extremes are rarely used. Malicious and broken callers can >>> still cause overflow at 68 years, so you have to check for it and >>> handle it. The limit of 194 days is just as good for timeouts. >> >> >> I think the phk's proposal is better. About your overflow objection, >> I think is really unlikely to happen, but better safe than sorry. > > > It's very easy for applications to cause kernel overflow using valid > syscall args like tv_sec = TIME_T_MAX for a relative time in > nanosleep(). Adding TIME_T_MAX to the current time in seconds overflow > for all current times except for the first second after the Epoch. > There is no difference between the overflow for 32-bit and 64-bit > time_t's for this. This is now mostly handled so that the behaviour is > harmless although wrong. E.g., the timeout might become negative, > and then since it is not a cookie it is silently replaced by a timeout > of 1 tick. In nanosleep(), IIRC there are further overflows that result > in returning early instead of retrying the 1-tick timeouts endlessly. > > Bruce Thanks, Davide