From owner-freebsd-arch@FreeBSD.ORG Mon Aug 12 20:27:38 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E7F8D4D8; Mon, 12 Aug 2013 20:27:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 58F082960; Mon, 12 Aug 2013 20:27:37 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 35AA9B93B; Mon, 12 Aug 2013 16:27:35 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: closedir - change in the libc Date: Mon, 12 Aug 2013 15:04:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <5204BD94.7050800@FreeBSD.org> <20130809105934.GA32419@stack.nl> <20130810213844.GA1400@garage.freebsd.pl> In-Reply-To: <20130810213844.GA1400@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201308121504.39774.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 12 Aug 2013 16:27:35 -0400 (EDT) Cc: Jilles Tjoelker , Mario Oshogbo 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: Mon, 12 Aug 2013 20:27:38 -0000 On Saturday, August 10, 2013 5:38:44 pm Pawel Jakub Dawidek wrote: > On Fri, Aug 09, 2013 at 12:59:34PM +0200, Jilles Tjoelker wrote: > > On Fri, Aug 09, 2013 at 11:59:48AM +0200, Mario Oshogbo wrote: > > > I'm a student attending in GSoC'13 in project "Write new features for > > > Capsicum" [1] and I would like to propose a little change to the libc. > > > > > In the libc we have the function opendir(3) and fdopendir(3) which are > > > responsible for opening directories. We also have function closedir(3) > > > which is responsible for free the structure allocated by two previous > > > funcions. > > > > > The problem with the closedir(3) is that he close fd used as argument of > > > fdopendir(3). I think programmer should be able to make a choice if he > > > want to close this descriptor automatically or not. Of course we are > > > able to use for dup(2) function and save fd before calling fdopendir(3) > > > to prevent closing but I think this is the one syscall which we could save. > > > > > To support the propose I would like to give some example. I working now > > > on making the fts(3) more sandbox friendly which means I would like to > > > remove all fchdir(2) functions and operate only on fd. One of the steps > > > I perform is changing the opendir(3) to the fdopendir(3). I also must > > > remember the fd of currently opened directory after perform fclosedir. > > > If we have N of directories we must perform N additional dup(2) and N > > > additional close(2) functions to save this fd. > > > > > So I would like to propose function called fdclosedir which will free > > > DIR structure but will not close fd attached to DIR structure. This > > > function also could return this fd which make it useful with the > > > opendir(3) function, when we don't know the fd but we would like free > > > DIR structure and perform some operations only on fd. I attach diff file > > > with my proposal of change. > > > > While this looks sensible, the only advantage is cleaner code and less > > memory usage. Instead of additional dup()/close(), you could also keep > > the DIR around as long as you need the fd. [...] > > This change is useful, I needed it in unrelated work to Mariusz's. > I wanted to "borrow" my directory descriptor to some function, which > were doing fdopendir(3) on it and to make it possible to not leak memory > on return from this function I had to dup(2) this descriptor. > > I'd love to see fdclose() for similar reasons (see bin/75767, among > others). Perl has some really gross code that wants to control the exact close of stdio fd. Currently it writes -1 to the _file member of FILE, and I'd love to make it use an "official" API for this. I think fdclose() would work fine for this and I'd like to see it as long as it will work well with Perl (and let us remove the gross _file hack from Perl). My interest is in making _file a private part of the future ABI as part of extending it from a short to an int. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Aug 15 10:10:20 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 21EA0EF6; Thu, 15 Aug 2013 10:10:20 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D8E1524A8; Thu, 15 Aug 2013 10:10:19 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 39BDC425E; Thu, 15 Aug 2013 10:10:18 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id E7F8C3C5; Thu, 15 Aug 2013 12:09:52 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: obrien@freebsd.org Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion References: <20130807183112.GA79319@dragon.NUXI.org> Date: Thu, 15 Aug 2013 12:09:52 +0200 In-Reply-To: <20130807183112.GA79319@dragon.NUXI.org> (David O'Brien's message of "Wed, 7 Aug 2013 11:31:12 -0700") Message-ID: <86pptfnu33.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Arthur Mesh , freebsd-arch@freebsd.org, secteam@freebsd.org, Philip Paeps 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: Thu, 15 Aug 2013 10:10:20 -0000 "David O'Brien" writes: > 20120913: > The random(4) support for the VIA hardware random number > generator (`PADLOCK') is no longer enabled unconditionally. > Add the PADLOCK_RNG option in the custom kernel config if > needed. The GENERIC kernels on i386 and amd64 do include the > option, so the change only affects the custom kernel > configurations. I still haven't received an answer to my question about options vs devices. AFAICT there is no reason whatsoever to have padlock or yarrow as kernel options rather than devices. The fact that they are available as modules is be a big hint that they should be devices, not options. The fact that we haven't been consistent in the past is not an excuse to continue making the same mistake in the present and future. I also believe that randomness is sufficiently important that we should have yarrow (or fortuna, when it materializes) in DEFAULTS. Users who don't want it (or prefer to load it as a module) can disable it with a nodevice entry in their kernel config. Also, rc scripts for services which require a PRNG (such as sshd) should complain and abort if kern.random.adaptors is empty. BTW, I see that the sysctl was changed (per my request) to return an empty string if no adaptors are present: if (LIST_EMPTY(&adaptors)) error =3D SYSCTL_OUT(req, "", strlen("")); LIST_FOREACH(rpp, &adaptors, entries) { if (0 !=3D SYSCTL_OUT(req, rpp->name, strlen(rpp->name))) break; } but if I read the code correctly, if multiple adaptors are present, their names will be concatenated with no separator. You probably want something like this: int comma =3D 0; /* ... */ LIST_FOREACH(rpp, &adaptors, entries) { if (!comma) { if (0 !=3D SYSCTL_OUT(req, ",", 1)) break; comma =3D 1; } if (0 !=3D SYSCTL_OUT(req, rpp->name, strlen(rpp->name))) break; } (and a minor nit: strlen("") is a strange way to spell 0...) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Aug 15 12:52:30 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DC168D8A for ; Thu, 15 Aug 2013 12:52:29 +0000 (UTC) (envelope-from mail.ohjcasjvpzephmc@emarketing.aplf.com) Received: from relay102.msgfocus.com (relay102.msgfocus.com [86.54.120.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 677DE2DCC for ; Thu, 15 Aug 2013 12:52:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=msgfocus.com; s=msgf; h=From:To:Message-ID:Reply-To:Date:Subject:Content-Transfer-Encoding:Content-Type; bh=dHmFR+cYTjjLhVWc/69D/moNGoBqdQVAk8I6/NC6nBU=; b=mbRdm8tK0sBko8n+F7KULvfClz75VkLDUu3yDbJpXH+yJAOoRBgUyiCIITe6/4+x0xN5b4civYziPSJHDJQe4yv0zSG+Cq51g3B30LY8lhirDGpzuJao8aLxzZ13Ynh0ogpMzOZG5gf6Esff1QQj2/BdXM7rNs2aWtsWVcLbCRk=; Subject: =?UTF-8?Q?Fashion=20Access=20=2D=20A=20fa?= =?UTF-8?Q?shion=20event=20in=20Hong=20K?= =?UTF-8?Q?ong=20you=20can=E2=80=99t=20affor?= =?UTF-8?Q?d=20to=20miss?= X-Mailer: MessageFocus Launcher (2.0-dev) Date: Thu, 15 Aug 2013 13:52:28 +0100 Message-ID: To: freebsd-arch@freebsd.org From: Fashion Access MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: APLF Ltd List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 12:52:30 -0000 If you cannot read this email, please click [1]here. Company: | , Fashion Accessories Purchasing Director ENG | [2]繁體 | [3]简体 Register Now to Avoid The Queue Enjoy 3 Days of Great Fashion Sourcing in Hong Kong __________________________________________________________________ Fashion AccessRegistration deadline is coming soon on Aug 17, 2013. Please [4]register now to get your electronic badge and avoid the queue onsite. __________________________________________________________________ This prestigious event is one of the leading fashion trade fairs in Asia, with emphasis on medium-to high-end bags, footwear, small leathergoods, fashion accessories and travelware. It gathers manufacturers, distributors, brands, designers and industry professionals from around the world and is the event where their latest fashion collections as well as upcoming fashion trends are presented. Special Airfares Special Airfare Offers for Fashion Access visitors, please [5]click here. Official Online Media Partner: Official Travel Agent: Follow us: APLF Limited 17/F China Resources Building 26 Harbour Road Wanchai Hong Kong [6]www.aplf.com T: 852 2827 6211 F: 852 3749 7310 Organisers: APLF Ltd Managers: UBM Asia Ltd [7]www.fashionaccess.aplf.com This message is sent to you by APLF Ltd. This newsletter is intended for the fashion buyers in your company. If you are a proper recipient and wish to contact a Fashion Access representative for more information on the fair, please [8]click here. If this email has been sent to the wrong person, please forward to the right colleague or click on [9]Subscribe a colleague. We will cease to use your personal data for direct marketing purposes without any charge to you if you so request. To unsubscribe from our newsletter, click on [10]unsubscribe. You may also contact us at [11]info@aplf.com. Ref. No.: INFASHION_FT01243 | Country: Russia [12]www.f [13]ashionaccess.aplf.com References Visible links 1. http://emarketing.aplf.com/c/16rXIpwXyD6QHfgV1vLlci 2. http://emarketing.aplf.com/c/16rZOi8fr2m9O08KRB3nUE 3. http://emarketing.aplf.com/c/16s0ReqTneYOmnzFMDHpgP 4. http://emarketing.aplf.com/c/16s1UaJxjrBsUL0AHGlqD0 5. http://emarketing.aplf.com/c/16s403kPbQQM1vSqxLDtlm 6. http://emarketing.aplf.com/c/16sahH8GP4AHlMtW41vBuq 7. http://emarketing.aplf.com/c/16sbkDrkLhdlU9UQZ49CQB 8. mailto:info@aplf.com?subject=Visitor%20Enquiry%20-%20Fashion%20Access 9. http://emarketing.aplf.com/c/16scnzJYHtQ0sxlLU6NEcM 10. mailto:unsubscribe@fashionaccess.aplf.com?subject=Unsubscribe%20Fashion%20Access%20eNewsletter 11. mailto:info@aplf.com 12. http://emarketing.aplf.com/c/16sdqw2CDGsF0UMGP9rFyX 13. http://emarketing.aplf.com/c/16setslgzT5jzidBKc5GV8 Hidden links: 14. http://emarketing.aplf.com/c/16rYLlPBuPJvfCHPWypmyt 15. http://emarketing.aplf.com/c/16s2X72bfEe7t8rvCIZrZb 16. http://emarketing.aplf.com/c/16s52ZDt83tqzTjlsOhuHx 17. http://emarketing.aplf.com/c/16s78SeL0sIJGEbbiTzxpT 18. http://emarketing.aplf.com/c/16s8bOxoWFlof1C6dWdyM4 19. http://emarketing.aplf.com/c/16s9eKQ2SRY2Np318YRA8f From owner-freebsd-arch@FreeBSD.ORG Thu Aug 15 23:17:18 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E5C51B2D; Thu, 15 Aug 2013 23:17:18 +0000 (UTC) (envelope-from arthurmesh@gmail.com) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AB7252F77; Thu, 15 Aug 2013 23:17:18 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id uo5so1344755pbc.37 for ; Thu, 15 Aug 2013 16:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=4BOHwSCHHbXoVGR5WM24td3ahM3lEYD0CclrUskU+WM=; b=lfQJaH7cKP1zZtnISSDDdKETdtTY9Of5hx2SZMNcNPwQ2W19dvPwTUjYpeNt+jYxUI bP48PcBuG0zSSFE4AzUrMhCLOzErN+QsIhqxPBU34A4DBsoBiruKEB+YconSZPLhRShM YA2zeYp0NyIFaONRB3HKnxa310bvF50PKnI1oVVTWFubAPt2yyiAr91ZMUbjWyKJMeXq uhSTaRlmvvIkLfO+plPoXq0IgD8f+UsCCgZmSLtPuwP34pok0/a5WyQUm13nnQ+8G6ue 9U1qDwfb/OVRP0TJ4bSiAIpIoJMXi/2oD/+L3ZVleu3eKxBETxc5y5iXHXCGKNTdhVsq v6Bw== X-Received: by 10.68.211.194 with SMTP id ne2mr18271407pbc.40.1376608638395; Thu, 15 Aug 2013 16:17:18 -0700 (PDT) Received: from x96.org (x96.org. [64.85.165.177]) by mx.google.com with ESMTPSA id xs1sm2034274pac.7.2013.08.15.16.17.16 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 15 Aug 2013 16:17:17 -0700 (PDT) Date: Thu, 15 Aug 2013 16:17:13 -0700 From: Arthur Mesh To: Dag-Erling Sm??rgrav Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130815231713.GD76666@x96.org> References: <20130807183112.GA79319@dragon.NUXI.org> <86pptfnu33.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86pptfnu33.fsf@nine.des.no> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org, secteam@freebsd.org, Philip Paeps 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: Thu, 15 Aug 2013 23:17:19 -0000 On Thu, Aug 15, 2013 at 12:09:52PM +0200, Dag-Erling Sm??rgrav wrote: > I still haven't received an answer to my question about options vs > devices. AFAICT there is no reason whatsoever to have padlock or yarrow > as kernel options rather than devices. The fact that they are available > as modules is be a big hint that they should be devices, not options. > The fact that we haven't been consistent in the past is not an excuse to > continue making the same mistake in the present and future. I agree that devices make more sense for yarrow/rdrand/nehemiah. We'll have a patch ready for review by so@ soon. > I also believe that randomness is sufficiently important that we should > have yarrow (or fortuna, when it materializes) in DEFAULTS. Users who > don't want it (or prefer to load it as a module) can disable it with a > nodevice entry in their kernel config. If we go this path, then random itself should also go in to DEFAULTS. Agreed? Does change to DEFAULTS need review by someone other than so@? > BTW, I see that the sysctl was changed (per my request) to return an > empty string if no adaptors are present: > > if (LIST_EMPTY(&adaptors)) > error = SYSCTL_OUT(req, "", strlen("")); > > LIST_FOREACH(rpp, &adaptors, entries) { > if (0 != SYSCTL_OUT(req, rpp->name, strlen(rpp->name))) > break; > } > > but if I read the code correctly, if multiple adaptors are present, > their names will be concatenated with no separator. You probably want > something like this: Yes, it's a bug. David already has a patch (almost) ready for review by so@. Thanks From owner-freebsd-arch@FreeBSD.ORG Fri Aug 16 00:26:29 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8B4F8761; Fri, 16 Aug 2013 00:26:29 +0000 (UTC) (envelope-from arthurmesh@gmail.com) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 50E272269; Fri, 16 Aug 2013 00:26:29 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id x10so1465396pdj.15 for ; Thu, 15 Aug 2013 17:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=cy+PsL/Tx//2TewwvcuS9XEmgrAXvxbajnoSEWEfCMI=; b=WDoU0Yu1cwxqLW11SGNcMPbA8oe7ZupHZGOJsBXukMdLgtuHSdrGRJTfDC9IxQ8Axf mT5TqqBfBkKJ4iDgcvoSKvNADQMBeQdLDhEK4airquuTc0mqjPE1m0CKg1nudKlddE6b lfia5IDJe+qroEDuOU8O3k/9fUmEnbueAA7+xYo4Pv+4BSbuDKDVzKm03DrtgLcgKc1j y3aoLwyd+WBAtYjWAHP5hLoN+EetzHji/MpThg6f8G4NM90bqYvmg1GXaa16yPxkNWxV rC8/lFhA8EUElUMGa5TPm6I1odEjx66pD8TuYOOfuJSph/hspBbRNnp1AUtTXIibVGAG E/Tg== X-Received: by 10.66.241.34 with SMTP id wf2mr177595pac.111.1376612788943; Thu, 15 Aug 2013 17:26:28 -0700 (PDT) Received: from x96.org (x96.org. [64.85.165.177]) by mx.google.com with ESMTPSA id vu5sm2298274pab.10.2013.08.15.17.26.26 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 15 Aug 2013 17:26:28 -0700 (PDT) Date: Thu, 15 Aug 2013 17:26:25 -0700 From: Arthur Mesh To: Dag-Erling Sm??rgrav Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130816002625.GE76666@x96.org> References: <20130807183112.GA79319@dragon.NUXI.org> <86pptfnu33.fsf@nine.des.no> <20130815231713.GD76666@x96.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130815231713.GD76666@x96.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org, secteam@freebsd.org, Philip Paeps 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: Fri, 16 Aug 2013 00:26:29 -0000 On Thu, Aug 15, 2013 at 04:17:13PM -0700, Arthur Mesh wrote: > I agree that devices make more sense for yarrow/rdrand/nehemiah. We'll have a > patch ready for review by so@ soon. Are you okay with the following? If so, I'll ask obrien@ to commit it and note the change in UPDATING. Also, how do we deal with i386/amd64 specific devices in LINT? Thanks Index: sys/amd64/conf/GENERIC =================================================================== --- sys/amd64/conf/GENERIC (revision 254389) +++ sys/amd64/conf/GENERIC (working copy) @@ -292,8 +292,8 @@ # Pseudo devices. device loop # Network loopback device random # Entropy device -options PADLOCK_RNG # VIA Padlock RNG -options RDRAND_RNG # Intel Bull Mountain RNG +device padlock_rng # VIA Padlock RNG +device rdrand_rng # Intel Bull Mountain RNG device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. Index: sys/conf/options.amd64 =================================================================== --- sys/conf/options.amd64 (revision 254389) +++ sys/conf/options.amd64 (working copy) @@ -68,7 +68,3 @@ # options for the Intel C600 SAS driver (isci) ISCI_LOGGING opt_isci.h - -# hw random number generators for random(4) -PADLOCK_RNG opt_cpu.h -RDRAND_RNG opt_cpu.h Index: sys/conf/options.i386 =================================================================== --- sys/conf/options.i386 (revision 254389) +++ sys/conf/options.i386 (working copy) @@ -123,7 +123,3 @@ # options for the Intel C600 SAS driver (isci) ISCI_LOGGING opt_isci.h - -# hw random number generators for random(4) -PADLOCK_RNG opt_cpu.h -RDRAND_RNG opt_cpu.h Index: sys/i386/conf/GENERIC =================================================================== --- sys/i386/conf/GENERIC (revision 254389) +++ sys/i386/conf/GENERIC (working copy) @@ -306,8 +306,8 @@ # Pseudo devices. device loop # Network loopback device random # Entropy device -options PADLOCK_RNG # VIA Padlock RNG -options RDRAND_RNG # Intel Bull Mountain RNG +device padlock_rng # VIA Padlock RNG +device rdrand_rng # Intel Bull Mountain RNG device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. From owner-freebsd-arch@FreeBSD.ORG Fri Aug 16 08:03:45 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B3C95D14; Fri, 16 Aug 2013 08:03:45 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 739A426BA; Fri, 16 Aug 2013 08:03:45 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 087C34424; Fri, 16 Aug 2013 08:03:38 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 2C8A0525; Fri, 16 Aug 2013 10:03:43 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Arthur Mesh Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion References: <20130807183112.GA79319@dragon.NUXI.org> <86pptfnu33.fsf@nine.des.no> <20130815231713.GD76666@x96.org> <20130816002625.GE76666@x96.org> Date: Fri, 16 Aug 2013 10:03:43 +0200 In-Reply-To: <20130816002625.GE76666@x96.org> (Arthur Mesh's message of "Thu, 15 Aug 2013 17:26:25 -0700") Message-ID: <86siyakqow.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org, secteam@freebsd.org, Philip Paeps 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: Fri, 16 Aug 2013 08:03:45 -0000 Arthur Mesh writes: > Are you okay with the following? Yes. > If so, I'll ask obrien@ to commit it and note the change in > UPDATING. Also, how do we deal with i386/amd64 specific devices in > LINT? Not sure what you mean by that. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Aug 16 16:49:52 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7C4A028F; Fri, 16 Aug 2013 16:49:52 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 408572385; Fri, 16 Aug 2013 16:49:52 +0000 (UTC) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VANDi-000OuT-AF; Fri, 16 Aug 2013 18:49:50 +0200 Message-ID: <520E5829.9090003@FreeBSD.org> Date: Fri, 16 Aug 2013 18:49:45 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130816 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jung-uk Kim Subject: Re: [PATCH] Atomic swap and test-and-set References: <51F81A74.4030009@FreeBSD.org> <20130731173247.GK4972@kib.kiev.ua> <51F96D2C.6030109@FreeBSD.org> <51FAFFDF.7040309@FreeBSD.org> In-Reply-To: <51FAFFDF.7040309@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2CKESMXUDOACRFEALDAUS" Cc: 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: Fri, 16 Aug 2013 16:49:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2CKESMXUDOACRFEALDAUS Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02.08.2013 02:39, Jung-uk Kim wrote: > I just created a branch and committed the patches because the final > version grew too big. >=20 > http://svnweb.freebsd.org/base/projects/atomic64 Hi Jung-uk! I applied your work (taken tokday from projects/atomic64) and the patches to drm2 and radeon today and X.Org is running with them now. So far, no regression spotted. Do you know if your branch will be committed to HEAD before 10.0? --=20 Jean-S=E9bastien P=E9dron ------enig2CKESMXUDOACRFEALDAUS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIOWC4ACgkQa+xGJsFYOlM9aACfRqMUIjJyShT2HqzYbPfk5MS0 PKUAoM+x9zwOzaeFk0YhxE8PwAp021aO =+ROr -----END PGP SIGNATURE----- ------enig2CKESMXUDOACRFEALDAUS-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 16 17:26:17 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 30DD5373; Fri, 16 Aug 2013 17:26:17 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E9DE625DF; Fri, 16 Aug 2013 17:26:16 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VANmu-000H4X-Ec; Fri, 16 Aug 2013 18:26:13 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_61BE7366-FF96-45D4-95CA-0C61B1CBA128"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <20130816002625.GE76666@x96.org> Date: Fri, 16 Aug 2013 18:26:06 +0100 Message-Id: <9B274F48-0C88-4117-BEAC-1A555772A3C5@grondar.org> References: <20130807183112.GA79319@dragon.NUXI.org> <86pptfnu33.fsf@nine.des.no> <20130815231713.GD76666@x96.org> <20130816002625.GE76666@x96.org> To: Arthur Mesh X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 Cc: Dag-Erling Sm??rgrav , Philip Paeps , secteam@freebsd.org, 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: Fri, 16 Aug 2013 17:26:17 -0000 --Apple-Mail=_61BE7366-FF96-45D4-95CA-0C61B1CBA128 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 16 Aug 2013, at 01:26, Arthur Mesh wrote: > On Thu, Aug 15, 2013 at 04:17:13PM -0700, Arthur Mesh wrote: >> I agree that devices make more sense for yarrow/rdrand/nehemiah. = We'll have a >> patch ready for review by so@ soon. >=20 > Are you okay with the following? Looks OK to me. When I commit Fortuna, I'll also be adding (back) options YARROW_RNG and FORTUNA_RNG, with the Yarrow one in the various DEFAULTS files for now. I'll not do that until your current work is settled. M --=20 Mark R V Murray --Apple-Mail=_61BE7366-FF96-45D4-95CA-0C61B1CBA128 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUg5gs958vKOKE6LNAQqoZAP9F9mKAIhAgWTAlxeF8jTx/KAvn1a3THtW 03I/gpeXgPCO/vmYPza3hDTex1BqPwQlf8dfkWfU8Bd2Va3P8RBCtxofpPtG75j2 obD9wOy3vkETiEVqdOTRHm28nNB43TI2AZmp51c50ksJd1ToI0B9gdfdQepBWNGi vUIeUHz93+w= =D48/ -----END PGP SIGNATURE----- --Apple-Mail=_61BE7366-FF96-45D4-95CA-0C61B1CBA128-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 16 17:29:09 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EAEE3446; Fri, 16 Aug 2013 17:29:09 +0000 (UTC) (envelope-from arthurmesh@gmail.com) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B0ECF25F2; Fri, 16 Aug 2013 17:29:09 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id lf1so2132870pab.10 for ; Fri, 16 Aug 2013 10:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=U1Z2fo4xpG71Quoi4iZcx3Djm19O4f0Gn97fImUYTjM=; b=Lqqy+UwccJgSGMN4M1dEZXhVyzA1WkRUATM4nKoqjwY4WXBsYfunQoMcxhxi09f00o TzgC+smMe3de+65tnP99F0d6M55K5heyki4/zq0NVp8Zi8z0Ru6azbnZ8d6E1bFs/L6v rtXb2Pe+dZ/+bTTL/f3SlRJCsVqunauh3q93pBrqJEdZuxAAgREIkvavuJ02otbSQs5Z yUhEg7ZfT1tcv72/rXTZFq7tKIzhrjRuNUVIZ5cqvBAyqE5Qx3puXmYTa4WRoZBtkAfB xOpA8H6P12pBOAIm23nGrY4ipyfjrlQE/Hx4SgQ8ToFpNraHLDVG+6CRXVsMRto1t+Ob d8Cg== X-Received: by 10.66.122.99 with SMTP id lr3mr2259147pab.187.1376674149310; Fri, 16 Aug 2013 10:29:09 -0700 (PDT) Received: from x96.org (x96.org. [64.85.165.177]) by mx.google.com with ESMTPSA id z14sm3313563pbt.0.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 16 Aug 2013 10:29:08 -0700 (PDT) Date: Fri, 16 Aug 2013 10:29:04 -0700 From: Arthur Mesh To: Dag-Erling Sm??rgrav Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130816172904.GF76666@x96.org> References: <20130807183112.GA79319@dragon.NUXI.org> <86pptfnu33.fsf@nine.des.no> <20130815231713.GD76666@x96.org> <20130816002625.GE76666@x96.org> <86siyakqow.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86siyakqow.fsf@nine.des.no> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org, secteam@freebsd.org, Philip Paeps 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: Fri, 16 Aug 2013 17:29:10 -0000 On Fri, Aug 16, 2013 at 10:03:43AM +0200, Dag-Erling Sm??rgrav wrote: > > If so, I'll ask obrien@ to commit it and note the change in > > UPDATING. Also, how do we deal with i386/amd64 specific devices in > > LINT? > > Not sure what you mean by that. I thought it would be prudent to add rdrand_rng/padlock_rng devices in to LINT kernel. But since both of these devices are platform specific (amd64/i386), I am not sure about the preferred way to accomplish that. Thanks From owner-freebsd-arch@FreeBSD.ORG Fri Aug 16 17:31:36 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 93ECC526; Fri, 16 Aug 2013 17:31:36 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <520E6189.80509@FreeBSD.org> Date: Fri, 16 Aug 2013 13:29:45 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130814 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= Subject: Re: [PATCH] Atomic swap and test-and-set References: <51F81A74.4030009@FreeBSD.org> <20130731173247.GK4972@kib.kiev.ua> <51F96D2C.6030109@FreeBSD.org> <51FAFFDF.7040309@FreeBSD.org> <520E5829.9090003@FreeBSD.org> In-Reply-To: <520E5829.9090003@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: 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: Fri, 16 Aug 2013 17:31:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-08-16 12:49:45 -0400, Jean-S￩bastien P￩dron wrote: > On 02.08.2013 02:39, Jung-uk Kim wrote: >> I just created a branch and committed the patches because the >> final version grew too big. >> >> http://svnweb.freebsd.org/base/projects/atomic64 > > Hi Jung-uk! > > I applied your work (taken tokday from projects/atomic64) and the > patches to drm2 and radeon today and X.Org is running with them > now. So far, no regression spotted. Thanks for testing. > Do you know if your branch will be committed to HEAD before 10.0? That's the plan ATM. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJSDmGJAAoJECXpabHZMqHOwowH/jnG98fByCsv3v9KueWSt6xd dJvLeQuPTek6VOrAYu+rIwpQX33OGDHU9QYiBNYZF2KHXaKTcuAczXhob/XDiUun YiWCh5AHLlgtX+p8GGQGLS0zliZtpZLlO+O85qlzHHFaFGjLMn2X+syvFmepimcc u0OFNsz2MIukvT++P5L8zM82E+C2w3HtJjkBFTKvvn6Rc7Pp1XNHJUVDs5OxjW8g zZI2VWBznRBUYenRCr5qALqtBzlfoYhB+IX/VBLhxVSvW1bB3G/z5bFuYlwERVE3 UhKAeWwDFfUmNFsSrTjzFylVoNLhkUpjsnTo3TQtPYDqPSio83CmVLGDaJXsYdQ= =ecWq -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 16 19:03:10 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 217CDFA9; Fri, 16 Aug 2013 19:03:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EA6F52B44; Fri, 16 Aug 2013 19:03:09 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E11FFB941; Fri, 16 Aug 2013 15:03:07 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Date: Fri, 16 Aug 2013 14:02:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <20130807183112.GA79319@dragon.NUXI.org> <86siyakqow.fsf@nine.des.no> <20130816172904.GF76666@x96.org> In-Reply-To: <20130816172904.GF76666@x96.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308161402.05688.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 16 Aug 2013 15:03:08 -0400 (EDT) Cc: Arthur Mesh , Dag-Erling Sm??rgrav , secteam@freebsd.org, Philip Paeps 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: Fri, 16 Aug 2013 19:03:10 -0000 On Friday, August 16, 2013 1:29:04 pm Arthur Mesh wrote: > On Fri, Aug 16, 2013 at 10:03:43AM +0200, Dag-Erling Sm??rgrav wrote: > > > If so, I'll ask obrien@ to commit it and note the change in > > > UPDATING. Also, how do we deal with i386/amd64 specific devices in > > > LINT? > > > > Not sure what you mean by that. > > I thought it would be prudent to add rdrand_rng/padlock_rng devices in > to LINT kernel. But since both of these devices are platform specific > (amd64/i386), I am not sure about the preferred way to accomplish that. You can put the relevant entries in sys/{amd64,i386}/conf/NOTES. LINT is generated by concatenating sys/conf/NOTES and sys/${arch}/conf/NOTES. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Sat Aug 17 08:32:55 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 47EB589B for ; Sat, 17 Aug 2013 08:32:55 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E30872C3C for ; Sat, 17 Aug 2013 08:32:53 +0000 (UTC) Received: from alph.d.allbsd.org (p2049-ipbf1102funabasi.chiba.ocn.ne.jp [122.26.101.49]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r7H8WZ3w056890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 17 Aug 2013 17:32:45 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r7H8WXMq062177 for ; Sat, 17 Aug 2013 17:32:35 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sat, 17 Aug 2013 17:30:19 +0900 (JST) Message-Id: <20130817.173019.1478850854128616078.hrs@allbsd.org> To: arch@FreeBSD.org Subject: suspend/resume time-gap and expiration timers in network stack From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Sat_Aug_17_17_30_19_2013_496)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Sat, 17 Aug 2013 17:32:45 +0900 (JST) X-Spam-Status: No, score=-90.6 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,RCVD_IN_PBL,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.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: Sat, 17 Aug 2013 08:32:55 -0000 ----Security_Multipart0(Sat_Aug_17_17_30_19_2013_496)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Sat_Aug_17_17_30_19_2013_036)--" Content-Transfer-Encoding: 7bit ----Next_Part(Sat_Aug_17_17_30_19_2013_036)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I recently committed s/time_second/time_uptime/ replacement in sys/netinet6 which was done in sys/netinet some years ago. It works well and should be more robust against time_second deviation (by NTP, for example). However, IPv6 default routers and prefixes do not expire as before if the machine is suspended and then resumed after a long time, say, 3 days. I think the impact is limited because suspend/resume causes to reset all of the physical network interfaces in some way, but in some cases the decayed entries can persist. So I would like your comments about the following idea to solve this: 1. Record RTC value upon suspend. 2. Calculate the time-gap by using the recorded value and the current one upon resume. 3. Store the calculated time-gap in time_uptime_gap variable and use (time_uptime + time_uptime_gap) for expiration timers. If there is no suspend/resume event, nothing happens. If any, the time-gap is added to the expiration time. The time_uptime_gap variable is always positive, so (time_uptime + time_uptime_gap) never goes backwards. A experimental patch is attached. Changes include the following: ==== - Add clock_suspend_stamp() and clock_resume_fixup() functions to calculate suspend/resume time-gap. clock_suspend_stamp() record an RTC value just before disabling timer, and clock_resume_fixup() store the time-gap into time_uptime_gap variable. Ideally, time_uptime + time_uptime_gap becomes equal to the elapsed time since boottime. - Add time-gap calculation in ACPI suspend/resume. - Add kern.clock_suspend_stamp and kern.clock_resume_fixup sysctls to allow time-gap calculation from userland. These are write-only, and setting them to non-zero calls the functions. Typically, kern.clock_suspend_stamp should be set to 1 just before suspend, and kern.clock_resume_fixup should be set to 1 just after resume. kern.clock_resume_fixup is idempotent. - Add TIME_UPTIME_CALED macro. This is defined as (time_uptime + time_uptime_gap). - Use TIME_UPTIME_CALED for expiration timers in sys/netinet6. ==== It is not so smart and I do not think it is commit-ready, but it helps you to understand what I want to do. While this implementation cares about only ACPI suspend/resume and timers in sys/netinet6, this can be applied to VM suspend/resume and sys/net and sys/netinet expiration timers like one for ARP table. -- Hiroki ----Next_Part(Sat_Aug_17_17_30_19_2013_036)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="uptime_gap.20130817-1.diff" - Add clock_suspend_stamp() and clock_resume_fixup() functions to calculate suspend/resume time-gap. clock_suspend_stamp() record an RTC value just before disabling timer, and clock_resume_fixup() store the time-gap into time_uptime_gap variable. Ideally, time_uptime + time_uptime_gap becomes equal to the elapsed time since boottime. - Add time-gap calculation in ACPI suspend/resume. - Add kern.clock_suspend_stamp and kern.clock_resume_fixup sysctls to allow time-gap calculation from userland. These are write-only, and setting them to non-zero calls the functions. Typically, kern.clock_suspend_stamp should be set to 1 just before suspend, and kern.clock_resume_fixup should be set to 1 just after resume. kern.clock_resume_fixup is idempotent. - Add TIME_UPTIME_CALED macro. This is defined as (time_uptime + time_uptime_gap). - Use TIME_UPTIME_CALED for expiration timers in sys/netinet6. ==== Index: sys/sys/clock.h =================================================================== --- sys/sys/clock.h (revision 254438) +++ sys/sys/clock.h (working copy) @@ -76,6 +76,8 @@ struct clocktime { int clock_ct_to_ts(struct clocktime *, struct timespec *); void clock_ts_to_ct(struct timespec *, struct clocktime *); void clock_register(device_t, long); +void clock_suspend_stamp(int); +void clock_resume_fixup(int); /* * BCD to decimal and decimal to BCD. Index: sys/sys/time.h =================================================================== --- sys/sys/time.h (revision 254438) +++ sys/sys/time.h (working copy) @@ -370,6 +370,8 @@ void resettodr(void); extern volatile time_t time_second; extern volatile time_t time_uptime; +extern volatile time_t time_uptime_gap; +#define TIME_UPTIME_CALED (time_uptime + time_uptime_gap) extern struct bintime boottimebin; extern struct timeval boottime; extern struct bintime tc_tick_bt; Index: sys/kern/kern_tc.c =================================================================== --- sys/kern/kern_tc.c (revision 254438) +++ sys/kern/kern_tc.c (working copy) @@ -106,6 +106,10 @@ int tc_min_ticktock_freq = 1; volatile time_t time_second = 1; volatile time_t time_uptime = 1; +volatile time_t time_uptime_gap = 0; +SYSCTL_LONG(_kern, OID_AUTO, uptime_gap, CTLFLAG_RD, + (void *)&time_uptime_gap, 0, + "Accumulated time-gap between system suspend and resume"); struct bintime boottimebin; struct timeval boottime; Index: sys/kern/subr_rtc.c =================================================================== --- sys/kern/subr_rtc.c (revision 254438) +++ sys/kern/subr_rtc.c (working copy) @@ -63,10 +63,12 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #ifdef FFCLOCK #include #endif #include +#include #include "clock_if.h" @@ -73,7 +75,16 @@ __FBSDID("$FreeBSD$"); static device_t clock_dev = NULL; static long clock_res; static struct timespec clock_adj; +static struct timespec ts_suspend; +static int clock_suspend_stamp_sysctl(SYSCTL_HANDLER_ARGS); +static int clock_resume_fixup_sysctl(SYSCTL_HANDLER_ARGS); +SYSCTL_PROC(_kern, OID_AUTO, clock_suspend_stamp, CTLTYPE_INT | CTLFLAG_WR, + NULL, 0, clock_suspend_stamp_sysctl, "I", + "Record time for kern.uptime_gap calculation"); +SYSCTL_PROC(_kern, OID_AUTO, clock_resume_fixup, CTLTYPE_INT | CTLFLAG_WR, + NULL, 0, clock_resume_fixup_sysctl, "I", "Fix up kern.uptime_gap"); + /* XXX: should be kern. now, it's no longer machdep. */ static int disable_rtc_set; SYSCTL_INT(_machdep, OID_AUTO, disable_rtc_set, CTLFLAG_RW, &disable_rtc_set, @@ -106,6 +117,85 @@ clock_register(device_t dev, long res) /* res has (intmax_t)clock_adj.tv_sec, (intmax_t)clock_adj.tv_nsec); } +void +clock_suspend_stamp(int arg) +{ + struct timespec ts; + int error; + + if (arg == 0) + return; + error = CLOCK_GETTIME(clock_dev, &ts); + if (error) { + printf("warning: clock_gettime failed (%d), the system time " + "upon suspend will be lost\n", error); + ts_suspend.tv_sec = 0; + ts_suspend.tv_nsec = 0; + } else + ts_suspend = ts; +} + +static int +clock_suspend_stamp_sysctl(SYSCTL_HANDLER_ARGS) +{ + int error, i; + + error = sysctl_wire_old_buffer(req, sizeof(int)); + if (error == 0) { + i = 0; + error = sysctl_handle_int(oidp, &i, 0, req); + } + if (error != 0 || req->newptr == NULL) + return (error); + clock_suspend_stamp(i); + return (0); +} + +void +clock_resume_fixup(int arg) +{ + struct timespec ts; + int error; + + if (arg == 0) + return; + /* When time upon suspend is unavailable, no calibration performed. */ + if (ts_suspend.tv_sec == 0) + return; + error = CLOCK_GETTIME(clock_dev, &ts); + if (error) + printf("warning: clock_gettime failed (%d), the system time " + "upon resume time will be lost\n", error); + else { + timespecsub(&ts, &ts_suspend); + if (ts.tv_sec >= 0) { + printf("info: %ld second time-gap detected.\n", + ts.tv_sec); + time_uptime_gap += ts.tv_sec; + } else + printf("warning: negative time-gap (%ld) " + "is detected.\n", ts.tv_sec); + } + ts_suspend.tv_sec = 0; + ts_suspend.tv_nsec = 0; +} + +static int +clock_resume_fixup_sysctl(SYSCTL_HANDLER_ARGS) +{ + int error, i; + + error = sysctl_wire_old_buffer(req, sizeof(int)); + if (error == 0) { + i = 0; + error = sysctl_handle_int(oidp, &i, 0, req); + } + if (error != 0 || req->newptr == NULL) + return (error); + clock_resume_fixup(i); + return (0); +} + /* * inittodr and settodr derived from the i386 versions written * by Christoph Robitschko , reintroduced and Index: sys/dev/acpica/acpi.c =================================================================== --- sys/dev/acpica/acpi.c (revision 254438) +++ sys/dev/acpica/acpi.c (working copy) @@ -38,6 +38,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -2742,6 +2743,7 @@ acpi_EnterSleepState(struct acpi_softc *sc, int st DELAY(sc->acpi_sleep_delay * 1000000); intr = intr_disable(); + clock_suspend_stamp(1); if (state != ACPI_STATE_S1) { sleep_result = acpi_sleep_machdep(sc, state); acpi_wakeup_machdep(sc, state, sleep_result, 0); @@ -2783,6 +2785,7 @@ acpi_EnterSleepState(struct acpi_softc *sc, int st } } + clock_resume_fixup(1); intr_restore(intr); /* call acpi_wakeup_machdep() again with interrupt enabled */ @@ -2797,6 +2800,7 @@ acpi_EnterSleepState(struct acpi_softc *sc, int st } else { status = AcpiEnterSleepState(state); AcpiLeaveSleepStatePrep(state); + clock_resume_fixup(1); intr_restore(intr); if (ACPI_FAILURE(status)) { device_printf(sc->acpi_dev, "AcpiEnterSleepState failed - %s\n", Index: sys/netinet6/icmp6.c =================================================================== --- sys/netinet6/icmp6.c (revision 254438) +++ sys/netinet6/icmp6.c (working copy) @@ -1931,8 +1931,8 @@ ni6_store_addrs(struct icmp6_nodeinfo *ni6, struct ltime = ND6_INFINITE_LIFETIME; else { if (ifa6->ia6_lifetime.ia6t_expire > - time_uptime) - ltime = htonl(ifa6->ia6_lifetime.ia6t_expire - time_uptime); + TIME_UPTIME_CALED) + ltime = htonl(ifa6->ia6_lifetime.ia6t_expire - TIME_UPTIME_CALED); else ltime = 0; } Index: sys/netinet6/in6.c =================================================================== --- sys/netinet6/in6.c (revision 254438) +++ sys/netinet6/in6.c (working copy) @@ -523,12 +523,12 @@ in6_control(struct socket *so, u_long cmd, caddr_t /* sanity for overflow - beware unsigned */ lt = &ifr->ifr_ifru.ifru_lifetime; if (lt->ia6t_vltime != ND6_INFINITE_LIFETIME && - lt->ia6t_vltime + time_uptime < time_uptime) { + lt->ia6t_vltime + TIME_UPTIME_CALED < TIME_UPTIME_CALED) { error = EINVAL; goto out; } if (lt->ia6t_pltime != ND6_INFINITE_LIFETIME && - lt->ia6t_pltime + time_uptime < time_uptime) { + lt->ia6t_pltime + TIME_UPTIME_CALED < TIME_UPTIME_CALED) { error = EINVAL; goto out; } @@ -631,13 +631,13 @@ in6_control(struct socket *so, u_long cmd, caddr_t ia->ia6_lifetime = ifr->ifr_ifru.ifru_lifetime; /* for sanity */ if (ia->ia6_lifetime.ia6t_vltime != ND6_INFINITE_LIFETIME) { - ia->ia6_lifetime.ia6t_expire = - time_uptime + ia->ia6_lifetime.ia6t_vltime; + ia->ia6_lifetime.ia6t_expire = TIME_UPTIME_CALED + + ia->ia6_lifetime.ia6t_vltime; } else ia->ia6_lifetime.ia6t_expire = 0; if (ia->ia6_lifetime.ia6t_pltime != ND6_INFINITE_LIFETIME) { - ia->ia6_lifetime.ia6t_preferred = - time_uptime + ia->ia6_lifetime.ia6t_pltime; + ia->ia6_lifetime.ia6t_preferred = TIME_UPTIME_CALED + + ia->ia6_lifetime.ia6t_pltime; } else ia->ia6_lifetime.ia6t_preferred = 0; break; @@ -1140,7 +1140,7 @@ in6_update_ifa(struct ifnet *ifp, struct in6_alias ia->ia_ifa.ifa_addr = (struct sockaddr *)&ia->ia_addr; ia->ia_addr.sin6_family = AF_INET6; ia->ia_addr.sin6_len = sizeof(ia->ia_addr); - ia->ia6_createtime = time_uptime; + ia->ia6_createtime = TIME_UPTIME_CALED; if ((ifp->if_flags & (IFF_POINTOPOINT | IFF_LOOPBACK)) != 0) { /* * XXX: some functions expect that ifa_dstaddr is not @@ -1167,7 +1167,7 @@ in6_update_ifa(struct ifnet *ifp, struct in6_alias } /* update timestamp */ - ia->ia6_updatetime = time_uptime; + ia->ia6_updatetime = TIME_UPTIME_CALED; /* set prefix mask */ if (ifra->ifra_prefixmask.sin6_len) { @@ -1217,12 +1217,12 @@ in6_update_ifa(struct ifnet *ifp, struct in6_alias ia->ia6_lifetime = ifra->ifra_lifetime; if (ia->ia6_lifetime.ia6t_vltime != ND6_INFINITE_LIFETIME) { ia->ia6_lifetime.ia6t_expire = - time_uptime + ia->ia6_lifetime.ia6t_vltime; + TIME_UPTIME_CALED + ia->ia6_lifetime.ia6t_vltime; } else ia->ia6_lifetime.ia6t_expire = 0; if (ia->ia6_lifetime.ia6t_pltime != ND6_INFINITE_LIFETIME) { ia->ia6_lifetime.ia6t_preferred = - time_uptime + ia->ia6_lifetime.ia6t_pltime; + TIME_UPTIME_CALED + ia->ia6_lifetime.ia6t_pltime; } else ia->ia6_lifetime.ia6t_preferred = 0; @@ -1240,7 +1240,7 @@ in6_update_ifa(struct ifnet *ifp, struct in6_alias */ if ((ifra->ifra_flags & IN6_IFF_DEPRECATED) != 0) { ia->ia6_lifetime.ia6t_pltime = 0; - ia->ia6_lifetime.ia6t_preferred = time_uptime; + ia->ia6_lifetime.ia6t_preferred = TIME_UPTIME_CALED; } /* * Make the address tentative before joining multicast addresses, Index: sys/netinet6/in6.h =================================================================== --- sys/netinet6/in6.h (revision 254438) +++ sys/netinet6/in6.h (working copy) @@ -361,11 +361,11 @@ extern const struct in6_addr in6addr_linklocal_all #define IFA6_IS_DEPRECATED(a) \ ((a)->ia6_lifetime.ia6t_pltime != ND6_INFINITE_LIFETIME && \ - (u_int32_t)((time_uptime - (a)->ia6_updatetime)) > \ + (u_int32_t)((TIME_UPTIME_CALED - (a)->ia6_updatetime)) > \ (a)->ia6_lifetime.ia6t_pltime) #define IFA6_IS_INVALID(a) \ ((a)->ia6_lifetime.ia6t_vltime != ND6_INFINITE_LIFETIME && \ - (u_int32_t)((time_uptime - (a)->ia6_updatetime)) > \ + (u_int32_t)((TIME_UPTIME_CALED - (a)->ia6_updatetime)) > \ (a)->ia6_lifetime.ia6t_vltime) #endif /* _KERNEL */ Index: sys/netinet6/in6_rmx.c =================================================================== --- sys/netinet6/in6_rmx.c (revision 254438) +++ sys/netinet6/in6_rmx.c (working copy) @@ -207,7 +207,7 @@ in6_mtuexpire(struct radix_node *rn, void *rock) panic("rt == NULL in in6_mtuexpire"); if (rt->rt_rmx.rmx_expire && !(rt->rt_flags & RTF_PROBEMTU)) { - if (rt->rt_rmx.rmx_expire <= time_uptime) { + if (rt->rt_rmx.rmx_expire <= TIME_UPTIME_CALED) { rt->rt_flags |= RTF_PROBEMTU; } else { ap->nextstop = lmin(ap->nextstop, @@ -226,7 +226,7 @@ in6_mtutimo_one(struct radix_node_head *rnh) struct mtuex_arg arg; arg.rnh = rnh; - arg.nextstop = time_uptime + MTUTIMO_DEFAULT; + arg.nextstop = TIME_UPTIME_CALED + MTUTIMO_DEFAULT; RADIX_NODE_HEAD_LOCK(rnh); rnh->rnh_walktree(rnh, in6_mtuexpire, &arg); RADIX_NODE_HEAD_UNLOCK(rnh); Index: sys/netinet6/ip6_forward.c =================================================================== --- sys/netinet6/ip6_forward.c (revision 254438) +++ sys/netinet6/ip6_forward.c (working copy) @@ -137,8 +137,8 @@ ip6_forward(struct mbuf *m, int srcrt) IN6_IS_ADDR_UNSPECIFIED(&ip6->ip6_src)) { IP6STAT_INC(ip6s_cantforward); /* XXX in6_ifstat_inc(rt->rt_ifp, ifs6_in_discard) */ - if (V_ip6_log_time + V_ip6_log_interval < time_uptime) { - V_ip6_log_time = time_uptime; + if (V_ip6_log_time + V_ip6_log_interval < TIME_UPTIME_CALED) { + V_ip6_log_time = TIME_UPTIME_CALED; log(LOG_DEBUG, "cannot forward " "from %s to %s nxt %d received on %s\n", @@ -405,8 +405,8 @@ skip_routing: IP6STAT_INC(ip6s_badscope); in6_ifstat_inc(rt->rt_ifp, ifs6_in_discard); - if (V_ip6_log_time + V_ip6_log_interval < time_uptime) { - V_ip6_log_time = time_uptime; + if (V_ip6_log_time + V_ip6_log_interval < TIME_UPTIME_CALED) { + V_ip6_log_time = TIME_UPTIME_CALED; log(LOG_DEBUG, "cannot forward " "src %s, dst %s, nxt %d, rcvif %s, outif %s\n", Index: sys/netinet6/ip6_mroute.c =================================================================== --- sys/netinet6/ip6_mroute.c (revision 254438) +++ sys/netinet6/ip6_mroute.c (working copy) @@ -1103,8 +1103,8 @@ X_ip6_mforward(struct ip6_hdr *ip6, struct ifnet * */ if (IN6_IS_ADDR_UNSPECIFIED(&ip6->ip6_src)) { IP6STAT_INC(ip6s_cantforward); - if (V_ip6_log_time + V_ip6_log_interval < time_uptime) { - V_ip6_log_time = time_uptime; + if (V_ip6_log_time + V_ip6_log_interval < TIME_UPTIME_CALED) { + V_ip6_log_time = TIME_UPTIME_CALED; log(LOG_DEBUG, "cannot forward " "from %s to %s nxt %d received on %s\n", Index: sys/netinet6/nd6.c =================================================================== --- sys/netinet6/nd6.c (revision 254441) +++ sys/netinet6/nd6.c (working copy) @@ -428,7 +428,7 @@ nd6_llinfo_settimer_locked(struct llentry *ln, lon ln->ln_ntick = 0; canceled = callout_stop(&ln->ln_timer_ch); } else { - ln->la_expire = time_uptime + tick / hz; + ln->la_expire = TIME_UPTIME_CALED + tick / hz; LLE_ADDREF(ln); if (tick > INT_MAX) { ln->ln_ntick = tick - INT_MAX; @@ -591,7 +591,7 @@ nd6_timer(void *arg) /* expire default router list */ TAILQ_FOREACH_SAFE(dr, &V_nd_defrouter, dr_entry, ndr) { - if (dr->expire && dr->expire < time_uptime) + if (dr->expire && dr->expire < TIME_UPTIME_CALED) defrtrlist_del(dr); } @@ -675,7 +675,7 @@ nd6_timer(void *arg) * prefix is not necessary. */ if (pr->ndpr_vltime != ND6_INFINITE_LIFETIME && - time_uptime - pr->ndpr_lastupdate > pr->ndpr_vltime) { + TIME_UPTIME_CALED - pr->ndpr_lastupdate > pr->ndpr_vltime) { /* * address expiration and prefix expiration are @@ -1033,9 +1033,9 @@ nd6_free(struct llentry *ln, int gc) * XXX: the check for ln_state would be redundant, * but we intentionally keep it just in case. */ - if (dr->expire > time_uptime) + if (dr->expire > TIME_UPTIME_CALED) nd6_llinfo_settimer_locked(ln, - (dr->expire - time_uptime) * hz); + (dr->expire - TIME_UPTIME_CALED) * hz); else nd6_llinfo_settimer_locked(ln, (long)V_nd6_gctimer * hz); @@ -1244,7 +1244,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet * drl->defrouter[i].flags = dr->flags; drl->defrouter[i].rtlifetime = dr->rtlifetime; drl->defrouter[i].expire = dr->expire + - (time_second - time_uptime); + (time_second - TIME_UPTIME_CALED); drl->defrouter[i].if_index = dr->ifp->if_index; i++; } @@ -1289,7 +1289,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet * oprl->prefix[i].expire = pr->ndpr_lastupdate + pr->ndpr_vltime + - (time_second - time_uptime); + (time_second - TIME_UPTIME_CALED); } else oprl->prefix[i].expire = maxexpire; } @@ -1512,7 +1512,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet * nbi->expire = 0; else nbi->expire = ln->la_expire + - (time_second - time_uptime); + (time_second - TIME_UPTIME_CALED); LLE_RUNLOCK(ln); break; } @@ -2292,7 +2292,7 @@ nd6_sysctl_drlist(SYSCTL_HANDLER_ARGS) return (error); d.flags = dr->flags; d.rtlifetime = dr->rtlifetime; - d.expire = dr->expire + (time_second - time_uptime); + d.expire = dr->expire + (time_second - TIME_UPTIME_CALED); d.if_index = dr->ifp->if_index; error = SYSCTL_OUT(req, &d, sizeof(d)); if (error != 0) @@ -2345,7 +2345,7 @@ nd6_sysctl_prlist(SYSCTL_HANDLER_ARGS) if (pr->ndpr_vltime < maxexpire - pr->ndpr_lastupdate) p.expire = pr->ndpr_lastupdate + pr->ndpr_vltime + - (time_second - time_uptime); + (time_second - TIME_UPTIME_CALED); else p.expire = maxexpire; } Index: sys/netinet6/nd6_rtr.c =================================================================== --- sys/netinet6/nd6_rtr.c (revision 254438) +++ sys/netinet6/nd6_rtr.c (working copy) @@ -282,7 +282,7 @@ nd6_ra_input(struct mbuf *m, int off, int icmp6len dr0.rtlifetime = 0; else dr0.rtlifetime = ntohs(nd_ra->nd_ra_router_lifetime); - dr0.expire = time_uptime + dr0.rtlifetime; + dr0.expire = TIME_UPTIME_CALED + dr0.rtlifetime; dr0.ifp = ifp; /* unspecified or not? (RFC 2461 6.3.4) */ if (advreachable) { @@ -874,7 +874,7 @@ nd6_prelist_add(struct nd_prefixctl *pr, struct nd free(new, M_IP6NDP); return(error); } - new->ndpr_lastupdate = time_uptime; + new->ndpr_lastupdate = TIME_UPTIME_CALED; if (newp != NULL) *newp = new; @@ -998,7 +998,7 @@ prelist_update(struct nd_prefixctl *new, struct nd pr->ndpr_vltime = new->ndpr_vltime; pr->ndpr_pltime = new->ndpr_pltime; (void)in6_init_prefix_ltimes(pr); /* XXX error case? */ - pr->ndpr_lastupdate = time_uptime; + pr->ndpr_lastupdate = TIME_UPTIME_CALED; } if (new->ndpr_raf_onlink && @@ -1136,7 +1136,7 @@ prelist_update(struct nd_prefixctl *new, struct nd if (lt6_tmp.ia6t_vltime == ND6_INFINITE_LIFETIME) remaininglifetime = ND6_INFINITE_LIFETIME; - else if (time_uptime - ifa6->ia6_updatetime > + else if (TIME_UPTIME_CALED - ifa6->ia6_updatetime > lt6_tmp.ia6t_vltime) { /* * The case of "invalid" address. We should usually @@ -1145,7 +1145,7 @@ prelist_update(struct nd_prefixctl *new, struct nd remaininglifetime = 0; } else remaininglifetime = lt6_tmp.ia6t_vltime - - (time_uptime - ifa6->ia6_updatetime); + (TIME_UPTIME_CALED - ifa6->ia6_updatetime); /* when not updating, keep the current stored lifetime. */ lt6_tmp.ia6t_vltime = remaininglifetime; @@ -1181,18 +1181,18 @@ prelist_update(struct nd_prefixctl *new, struct nd u_int32_t maxvltime, maxpltime; if (V_ip6_temp_valid_lifetime > - (u_int32_t)((time_uptime - ifa6->ia6_createtime) + - V_ip6_desync_factor)) { + (u_int32_t)((TIME_UPTIME_CALED - + ifa6->ia6_createtime) + V_ip6_desync_factor)) { maxvltime = V_ip6_temp_valid_lifetime - - (time_uptime - ifa6->ia6_createtime) - + (TIME_UPTIME_CALED - ifa6->ia6_createtime) - V_ip6_desync_factor; } else maxvltime = 0; if (V_ip6_temp_preferred_lifetime > - (u_int32_t)((time_uptime - ifa6->ia6_createtime) + - V_ip6_desync_factor)) { + (u_int32_t)((TIME_UPTIME_CALED - + ifa6->ia6_createtime) + V_ip6_desync_factor)) { maxpltime = V_ip6_temp_preferred_lifetime - - (time_uptime - ifa6->ia6_createtime) - + (TIME_UPTIME_CALED - ifa6->ia6_createtime) - V_ip6_desync_factor; } else maxpltime = 0; @@ -1207,7 +1207,7 @@ prelist_update(struct nd_prefixctl *new, struct nd } } ifa6->ia6_lifetime = lt6_tmp; - ifa6->ia6_updatetime = time_uptime; + ifa6->ia6_updatetime = TIME_UPTIME_CALED; } IF_ADDR_RUNLOCK(ifp); if (ia6_match == NULL && new->ndpr_vltime) { @@ -1988,7 +1988,7 @@ in6_tmpifadd(const struct in6_ifaddr *ia0, int for if (ia0->ia6_lifetime.ia6t_vltime != ND6_INFINITE_LIFETIME) { vltime0 = IFA6_IS_INVALID(ia0) ? 0 : (ia0->ia6_lifetime.ia6t_vltime - - (time_uptime - ia0->ia6_updatetime)); + (TIME_UPTIME_CALED - ia0->ia6_updatetime)); if (vltime0 > V_ip6_temp_valid_lifetime) vltime0 = V_ip6_temp_valid_lifetime; } else @@ -1996,7 +1996,7 @@ in6_tmpifadd(const struct in6_ifaddr *ia0, int for if (ia0->ia6_lifetime.ia6t_pltime != ND6_INFINITE_LIFETIME) { pltime0 = IFA6_IS_DEPRECATED(ia0) ? 0 : (ia0->ia6_lifetime.ia6t_pltime - - (time_uptime - ia0->ia6_updatetime)); + (TIME_UPTIME_CALED - ia0->ia6_updatetime)); if (pltime0 > V_ip6_temp_preferred_lifetime - V_ip6_desync_factor){ pltime0 = V_ip6_temp_preferred_lifetime - V_ip6_desync_factor; @@ -2054,11 +2054,11 @@ in6_init_prefix_ltimes(struct nd_prefix *ndpr) if (ndpr->ndpr_pltime == ND6_INFINITE_LIFETIME) ndpr->ndpr_preferred = 0; else - ndpr->ndpr_preferred = time_uptime + ndpr->ndpr_pltime; + ndpr->ndpr_preferred = TIME_UPTIME_CALED + ndpr->ndpr_pltime; if (ndpr->ndpr_vltime == ND6_INFINITE_LIFETIME) ndpr->ndpr_expire = 0; else - ndpr->ndpr_expire = time_uptime + ndpr->ndpr_vltime; + ndpr->ndpr_expire = TIME_UPTIME_CALED + ndpr->ndpr_vltime; return 0; } @@ -2070,7 +2070,7 @@ in6_init_address_ltimes(struct nd_prefix *new, str if (lt6->ia6t_vltime == ND6_INFINITE_LIFETIME) lt6->ia6t_expire = 0; else { - lt6->ia6t_expire = time_uptime; + lt6->ia6t_expire = TIME_UPTIME_CALED; lt6->ia6t_expire += lt6->ia6t_vltime; } @@ -2078,7 +2078,7 @@ in6_init_address_ltimes(struct nd_prefix *new, str if (lt6->ia6t_pltime == ND6_INFINITE_LIFETIME) lt6->ia6t_preferred = 0; else { - lt6->ia6t_preferred = time_uptime; + lt6->ia6t_preferred = TIME_UPTIME_CALED; lt6->ia6t_preferred += lt6->ia6t_pltime; } } ----Next_Part(Sat_Aug_17_17_30_19_2013_036)---- ----Security_Multipart0(Sat_Aug_17_17_30_19_2013_496)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlIPNJsACgkQTyzT2CeTzy3olQCcDHleTDL5LIW8oQ/3bGtpVWJD /hoAoJlQHiiGV+yu87eWGevWYtqKlWLt =oTkD -----END PGP SIGNATURE----- ----Security_Multipart0(Sat_Aug_17_17_30_19_2013_496)---- From owner-freebsd-arch@FreeBSD.ORG Sat Aug 17 14:50:21 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 89A71894; Sat, 17 Aug 2013 14:50:21 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 0D33B2B6E; Sat, 17 Aug 2013 14:50:21 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 3B1281041E16; Sun, 18 Aug 2013 00:50:12 +1000 (EST) Date: Sun, 18 Aug 2013 00:49:53 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Hiroki Sato Subject: Re: suspend/resume time-gap and expiration timers in network stack In-Reply-To: <20130817.173019.1478850854128616078.hrs@allbsd.org> Message-ID: <20130818004948.L4326@besplex.bde.org> References: <20130817.173019.1478850854128616078.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=bpB1Wiqi c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=-G4Y16xk-08A:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=lWkSEhi8E8gA:10 a=bnKvjGPC9WDuNAu6Xr4A:9 a=CjuIK1q_8ugA:10 Cc: 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: Sat, 17 Aug 2013 14:50:21 -0000 On Sat, 17 Aug 2013, Hiroki Sato wrote: > I recently committed s/time_second/time_uptime/ replacement in > sys/netinet6 which was done in sys/netinet some years ago. It works > well and should be more robust against time_second deviation (by NTP, > for example). However, IPv6 default routers and prefixes do not > expire as before if the machine is suspended and then resumed after a > long time, say, 3 days. > > I think the impact is limited because suspend/resume causes to reset > all of the physical network interfaces in some way, but in some cases > the decayed entries can persist. So I would like your comments about > the following idea to solve this: The monotonic clock has always been broken across suspend/resume inxi FreeBSD. Long ipv6 timeouts are only one of the things broken. If you fux the monotonic clock, then the ipv6 code shouldn't need any changes. POSIX.1 (2001-draft7.txt) specifies the monotonic clock as follows: %%% 6679 MON If the Monotonic Clock option is supported, all implementations shall support a clock_id of 6680 CLOCK_MONOTONIC defined in . This clock represents the monotonic clock for the 6681 system. For this clock, the value returned by clock_gettime( ) represents the amount of time (in 6682 seconds and nanoseconds) since an unspecified point in the past (for example, system start-up 6683 time, or the Epoch). This point does not change after system start-up time. The value of the 6684 CLOCK_MONOTONIC clock cannot be set via clock_settime( ). This function shall fail if it is 6685 invoked with a clock_id argument of CLOCK_MONOTONIC. %%% Note that the "unspecified point in the past" "does not change after system start-up [bogus word time]". This is very broken in FreeBSD. In FreeBSD, at least without the FFCLOCK complications, the point in the past is nominally the boot time, which is given by the variable boottimebin (or boottime), but the real time is misimplemented as the sum of boottimebin and the monotonic time and since the monotonic time never jumps, boottimebin must jump instead whenever the real time jumps. The jump occurs in tc_setclock(), so almost everything that calls there gives a bug. Some jumps are more real than others, but just 3 types of jump should change the boot time. Types of jumps: 1. when the system is initialized. Times are set by eventually calling tc_setclock. The real time and the boot time are statically initialized by 0. The first dynamic initialization is thus seen as a large jump forward of the real time. The boot time is then set to the real time, to maintain the (buggy) invariant real_time = monotonic_time + boottime. The monotonic time remains at 0, or at perhaps a small value of a few seconds that the boot has taken to reach this point. This jump of the boot time is correct, though it can only give a fuzzy setting for the boot time, since even if the monotonic time is nonzero at this point, it can only give the time since some earlier indeterminate point in the boot (several seconds after the boot started, when the hardware timer started being used). 2. Many systems have the RTC on wall clock time. Both of the times set by (1) are then wrong by the same large amount (10-11 hours here). The real time is normally fixed up by adjkerntz using settimeofday(2). This gives a large jump in the real time and a large jump in the boot time. Both jumps are correct. 3. Many systems set the real time more precisely using ntp. This is best done by ntpdate stepping the clock. If it is done by ntpd stepping the clock, then the jump will occur later and you don't have so much control over when it occurs. If it is done by ntpd slewing the clock, then the boot time doesn't get set more precisely. I think ntpd just uses settimeofday() or clock_settime() when it steps the clock. This calls tc_setclock(), and as usual jumps the boot time to match the jump in the real time. Both jumps are correct. When ntpd slews the clock, it uses ntp_adjtime() on FreeBSD. Plain adjtime() would do much the same. This makes micro-adjustments to the monotonic time which become micro-adjustments to the real time via the invariant real_time = monotonic_time + boottime. Strictly, adjusting the monotonic time is a bug when it is to fix an error in the current real time, but with sufficiently small micro-adjustments to slew ntpd's maximum amount of 1/128 (?) seconds, this doesn't cause any more problems than not doing the much smaller adjustments for relativistic effects. All other types of jumps of the boot time are bugs. After initialization, the boot time is whatever it is and can't change. 4. Leap seconds adjustments. boottimebin is jumps to maintain the invariant. This happens in tc_windup(), not in tc_setclock(). The jumps are rare and not very large, so no one usually notices the boot time being clobbered. 5. Any call to setimeofday() to do further adjustments of the real time. Perhaps you aren't using ntpd, or stopped ntpd or suspended and resumed and are fixing up times manually. This breaks the value of boottimebin (assuming that it was set correctly by steps 1-3) by jumping it by the same amount as the real time. 6. Calls to tc_setclock() on resume to fix up the real time. These clobber the boot time. But more seriously, the invariant and the clobbering of the boot time to maintai it break the monotonic time perfectly by allowing to not advance across long suspend/resume operations. The implementation should be something like: real_time = monotonic_time + base_time where base_time != boot_time but is updated similarly to the current boot_time, and boot_time which is updated similarly to the current boot_time only during initialization. Also, monotonic_time needs to be updated for (6) and possibly for (5) (to fix it up after anything stops seeing it advancing at very nearly a constant rate). To limit adjustments of boot_time to initialization, something like the machdep.disable_rtc_set sysctl could be used. It is not easy for tc_setclock() to determine if its context is for initialization. > 1. Record RTC value upon suspend. This should already be done to support fixing up the real time on resume. Both the real and monotonic times should be advanced on resume by - The acpica code that fixes up the real time on resume is hard to find. I can only find acpi_resync_clock(). This is under an __amd64__ ifdef and a boolean sysctl that defaults to on. It is very broken: % static void % acpi_resync_clock(struct acpi_softc *sc) % { % #ifdef __amd64__ % if (!acpi_reset_clock) % return; % % /* % * Warm up timecounter again and reset system clock. % */ % (void)timecounter->tc_get_timecount(timecounter); % (void)timecounter->tc_get_timecount(timecounter); % inittodr(time_second + sc->acpi_sleep_delay); % #endif % } The time_second + ... arg for inittodr() is probably out of date, but it is only used if reading the RTC hardware fails. This function is very broken since it doesn't use the RTC delta. It is basically missing all of the initialization steps (1)-(3), plus any later tracking of the real time done by ntp. The largest error is when the RTC is on wall clock time. Then the above gives an error of 10 hours or so. Old i386-isa only apm code tries to do the right thing, but is buggy in the details: % static struct timeval suspend_time; % static struct timeval diff_time; % % static int % pmtimer_suspend(device_t dev) % { % % microtime(&diff_time); % inittodr(0); % microtime(&suspend_time); % timevalsub(&diff_time, &suspend_time); % return (0); % } This abuses inittodr() to read the RTC time. It clobbers the current real time (and collateral state like boottimebin) by setting it to the current time. It then reads the RTC time with a second microtime(). There are races in this that may give errors of a second or 2, but these are unimportant compared with races from clobbering the current time. Otherwise, this caclulates the time adjustment correctly. There are now APIs for reading RTC times, but this old code hasn't been changed to use them. The only recent changes have been to remove spl()'s that gave hints about the necessary locking. % % static int % pmtimer_resume(device_t dev) % { % u_int second, minute, hour; % struct timeval resume_time, tmp_time; % % /* modified for adjkerntz */ % timer_restore(); /* restore the all timers */ Done better in resume methods. % inittodr(0); /* adjust time to RTC */ Same clobbering of real time as on suspend, so that we have a time that the adjustment applies to. % microtime(&resume_time); % getmicrotime(&tmp_time); % timevaladd(&tmp_time, &diff_time); Caclulate new real time to adjust to. But everything after this point is garbage. % % #ifdef FIXME % /* XXX THIS DOESN'T WORK!!! */ % time = tmp_time; This might have worked before timecounters. Now it just needs a tc_setclock(). But no timer-setting code is called except inittodr(0), so the calculated adjustment is never used and the result is the same as for acpi_resync_clock(). % #endif % % #ifdef PMTIMER_FIXUP_CALLTODO This became garbage before it was committed. But note that complete fixes for monotonic times also requires fixing timeouts. Most timeouts sleep on monotonic time, even when they should sleep on real time. You want the ones that expired during suspend/resume to time out soon after resume, but not all at once. I think PMTIMER_FIXUP_CALLTODO worked in a version of FreeBSD before it was committed by making them all time out at once. % /* Calculate the delta time suspended */ % timevalsub(&resume_time, &suspend_time); % /* Fixup the calltodo list with the delta time. */ % adjust_timeout_calltodo(&resume_time); % /* % * We've already calculated resume_time to be the delta between % * the suspend and the resume. % */ % second = resume_time.tv_sec; % #else /* !PMTIMER_FIXUP_CALLTODO */ % second = resume_time.tv_sec - suspend_time.tv_sec; % #endif /* PMTIMER_FIXUP_CALLTODO */ % hour = second / 3600; % second %= 3600; % minute = second / 60; % second %= 60; % log(LOG_NOTICE, "wakeup from sleeping state (slept %02d:%02d:%02d)\n", % hour, minute, second); % return (0); % } > 2. Calculate the time-gap by using the recorded value and the current > one upon resume. > > 3. Store the calculated time-gap in time_uptime_gap variable and use > (time_uptime + time_uptime_gap) for expiration timers. The gap needs to be added to the monotonic time. Then it will fix more than you want to know about, but nothing will need to add it later. There are some races in doing this addition, but tc_setclock() already has many races (it modifies the active multi-word boottime* variables with null locking), and then may reenter tc_windup(). Adding to the timehands variables is a bit trickier). The gaps are actually subtly different: RTC_gap = resume_RTC_time - susp_RTC_time resume_real_time = resume_RTC_time + (adj = susp_real_time - susp_RTC_time) = susp_real_time + RTC_gap. I think you should use: resume_mono_time = susp_mono_time + RTC_gap, but you actually use: resume_mono_time = orig_resume_mono_time + RTC_gap. The mono time will advance a bit after the RTC is read at suspend time, and it is important not to let the mono time go backwards, but the last formula counts a lot of mono time twice. > If there is no suspend/resume event, nothing happens. If any, the > time-gap is added to the expiration time. The time_uptime_gap > variable is always positive, so (time_uptime + time_uptime_gap) never > goes backwards. Locking is no simpler with addition of the gap when it is used. Even adding seconds only has a change of being atomic on 32-bit arches if time_t remains in seconds. For bintimes, there are much the same races adding the gap to the incomplete monotonic time as for adding frobbed boottimebin to the incomplete monotonic time to get the real time. Reads of boottimebin are locked by the generation count, modulo bugs in the locking. Writes of boottimebine are unlocked. Both boottimebin and the gap are rarely changed so races writing them are rarely lost. > A experimental patch is attached. Changes include the following: > > ==== > - Add clock_suspend_stamp() and clock_resume_fixup() functions to > calculate suspend/resume time-gap. clock_suspend_stamp() record > an RTC value just before disabling timer, and clock_resume_fixup() > store the time-gap into time_uptime_gap variable. Ideally, > time_uptime + time_uptime_gap becomes equal to the elapsed time > since boottime. I haven't fixed this since none of my machines do suspend right. I use very accurate (~1 usec) related fixups in the RTC interrupt handler. It basically calculates the gap every 64 seconds for later use. I only use this to fix up the real time after stopping in ddb. The fixup is done by tc_setclock(). Stopping clock updates in ddb is very like stopping in suspend/resume. tc_setlock() clobbers boottimebin by the amount of time spent stopped in ddb. The ~1 usec accuracy is obtained by synchronizing RTC reads with seconds rollovers and by adjusting for the current drift rate (drift is typically 5 usec/sec, so if ddb stops clock updates for 60 seconds, then the gap is 5 * 60 extra. After hours-long suspensions, you can't hope for microseconds accuracy, but should try to avoid seconds inaccuracies). > - Add time-gap calculation in ACPI suspend/resume. > > - Add kern.clock_suspend_stamp and kern.clock_resume_fixup sysctls to > allow time-gap calculation from userland. These are write-only, and > setting them to non-zero calls the functions. Typically, > kern.clock_suspend_stamp should be set to 1 just before suspend, > and kern.clock_resume_fixup should be set to 1 just after resume. > kern.clock_resume_fixup is idempotent. It's reasonable to do it all from userland. I delay the fixups for ddb by 3 seconds, and reject all backwards fixups and forwards fixups of more than 1 day. The patch is too large for me. This shouldn't take much more than twice the 15 lines taken by acpi_resync_clock() to do a buggy real time fixup (another 15 lines to do a non-buggy real time fixup, and the same to apply apply the same fixup to the monotonic time. Unfortunately, probably many more to untangle boottimebin). subr_rtc.c needs a clock-reading function to begin with, so that the pmtimer code can find the active clock without hacking on inittodr(). Bruce From owner-freebsd-arch@FreeBSD.ORG Sat Aug 17 17:27:44 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6B02880D; Sat, 17 Aug 2013 17:27:44 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 304B1224E; Sat, 17 Aug 2013 17:27:44 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 061053EB43; Sat, 17 Aug 2013 17:17:18 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.7/8.14.7) with ESMTP id r7HHHHKW010981; Sat, 17 Aug 2013 17:17:18 GMT (envelope-from phk@phk.freebsd.dk) To: Bruce Evans Subject: Re: suspend/resume time-gap and expiration timers in network stack In-reply-to: <20130818004948.L4326@besplex.bde.org> From: "Poul-Henning Kamp" References: <20130817.173019.1478850854128616078.hrs@allbsd.org> <20130818004948.L4326@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Sat, 17 Aug 2013 17:17:17 +0000 Message-ID: <10980.1376759837@critter.freebsd.dk> Cc: 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: Sat, 17 Aug 2013 17:27:44 -0000 In message <20130818004948.L4326@besplex.bde.org>, Bruce Evans writes: > The boot time is then set to the real time, > to maintain the (buggy) invariant real_time = monotonic_time + boottime. > real_time = monotonic_time + base_time That was a lot of verbiage just to change the name of a variable :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.