From owner-freebsd-arch@FreeBSD.ORG Wed Jan 2 17:09: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]) by hub.freebsd.org (Postfix) with ESMTP id DBCC8DEE for ; Wed, 2 Jan 2013 17:09:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7F42E17E1 for ; Wed, 2 Jan 2013 17:09:38 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id r02H9YJs040574; Wed, 2 Jan 2013 19:09:34 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua r02H9YJs040574 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id r02H9Y1b040573; Wed, 2 Jan 2013 19:09:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 2 Jan 2013 19:09:34 +0200 From: Konstantin Belousov To: Luigi Rizzo Subject: Re: [RFC/RFT] calloutng Message-ID: <20130102170934.GA82219@kib.kiev.ua> References: <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> <20130102162206.GA45701@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1XmnKQGVLLNJnMip" Content-Disposition: inline In-Reply-To: <20130102162206.GA45701@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Davide Italiano , Ian Lepore , Alexander Motin , freebsd-arch@freebsd.org, FreeBSD Current , Marius Strobl 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, 02 Jan 2013 17:09:38 -0000 --1XmnKQGVLLNJnMip Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 02, 2013 at 05:22:06PM +0100, Luigi Rizzo wrote: > On Wed, Jan 02, 2013 at 03:11:05PM +0200, Alexander Motin wrote: > ... > > > First of all, if you know that there is already a hardclock/statclock= /* > > > scheduled in [T_X, T_X+D] you just reuse that. This particular bullet > > > was ""no event scheduled in [T_X, T_X+D]" so you need to generate > > > a new one. > >=20 > > That is true, but my main point was about merging with external events, > > which I can't predict and the only way to merge is increase sleep perio= d, > > hoping for better. >=20 > ok, now i understand why you want to schedule for T_X+D. >=20 > Probably one way to close this discussion would be to provide > a sysctl so the sysadmin can decide which point in the interval > to pick when there is no suitable callout already scheduled. Isn't trying to synchronize to the external events in this way unsafe ? I remember, but cannot find the reference right now, a scheduler exploit(s) which completely hide malicious thread from the time accounting, by making it voluntary yielding right before statclock should fire. If statistic gathering could be piggy-backed on the external interrupt, and attacker can control the source of the external events, wouldn't this give her a handle ? --1XmnKQGVLLNJnMip Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ5GnNAAoJEJDCuSvBvK1BD7wP/AiejtH6wGLURiyHvqLN6rvo pjj0tVyGyBErD8Fk/iGaeT6Ok4mqMoKU2bNEGLE9FhC+9ixqxGJzZdGargtDSigq f5qDnnGx0ZYGRz9M/E66E8HJnUT0dLd4eb5zOPdHYUS4vceOdhXDOhRma68fRU4a pPsAPMVgZCFjh44MuL5Ip5hUYYXBvFqloMjsWX5QCm3oYm1mmAN6EX+45jO201sy BP10zANSKFD59QgFr8vWV9zBzx3dfeG6TjJFDKQ9UCV9OohxdrkFeanxE6cq7gxi kEjjUUNcCKiQ9XdzfdCawncYoO+9sioPrg+tHMLCaAPXOW+N8v9PGlPwUechS5kj HAdUwUhEOqFWppPSC9w89WaDGMUWDLo3DXSi+spk+towdaT3caZkKm+EVAmkCYqL xXwFNCmu/xHMLvqPUvnyH/6uq0DmNOHrtoJxKMMcP3fzRjdWFwzJYNMM6kMTDZGu /AcLEVJwU9+FgWGZgz+nAyQv62Z23YXk8nLOgUD33lS3zC4KV19onkhzYZ9XHQf2 TasP7/TFUgxjnU8l8QGwTgeb9oaHZHy2O4qH2jvPP3Eb22mkfoiaJHpVWrJ8iwek C7ZDUJVat0HIdazS6lE1geveBoDmINZemHyBK+f5XGYNfGUefVMqcSU77i8yOfFL 2h3QNlI93AdfFutRaPTU =oZCF -----END PGP SIGNATURE----- --1XmnKQGVLLNJnMip--