Date: Wed, 2 Jan 2013 19:09:34 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: Davide Italiano <davide@freebsd.org>, Ian Lepore <freebsd@damnhippie.dyndns.org>, Alexander Motin <mav@freebsd.org>, freebsd-arch@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>, Marius Strobl <marius@alchemy.franken.de> Subject: Re: [RFC/RFT] calloutng Message-ID: <20130102170934.GA82219@kib.kiev.ua> In-Reply-To: <20130102162206.GA45701@onelab2.iet.unipi.it> 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> <CAO4K=PUHAH=UNzMde0V2TwkN5vj3gw9hHj5yCQxDvdUn%2Buqv7w@mail.gmail.com> <20130102162206.GA45701@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130102170934.GA82219>