From owner-svn-src-all@freebsd.org Sat Dec 10 21:13:30 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3335C712E8; Sat, 10 Dec 2016 21:13:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D8B41062; Sat, 10 Dec 2016 21:13:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uBALDPu9061707 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 10 Dec 2016 23:13:25 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uBALDPu9061707 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uBALDPva061706; Sat, 10 Dec 2016 23:13:25 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 10 Dec 2016 23:13:25 +0200 From: Konstantin Belousov To: Gleb Smirnoff Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r309745 - in head: share/man/man9 sys/kern sys/sys Message-ID: <20161210211325.GT54029@kib.kiev.ua> References: <201612091758.uB9HwYC0087384@repo.freebsd.org> <20161209184117.GJ54029@kib.kiev.ua> <20161209185636.GJ27748@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161209185636.GJ27748@FreeBSD.org> User-Agent: Mutt/1.7.1 (2016-10-04) 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 autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 21:13:30 -0000 On Fri, Dec 09, 2016 at 10:56:36AM -0800, Gleb Smirnoff wrote: > Yes, this is expected. The interface isn't designed to be precise. So if > we hit limit, the next second result will be 20345 events exceeded the rate > instead of 20346 events. Note that the interface may legitimately give errors in the other direction as well, see below. The initial read of cr_ticks is racy, so one thread noting the condition of >= hz and executing counter_u64_zero() might race with another thread not observing the condition and executing counter_u64_add() in parallel. I believe this is possible even on relatively ordered arches like x86. Now, since counter_u64_add() is not atomic for the pcpu cell update (e.g. on x86), increment of the current pcpu cell might race with zeroing it, resulting in the old value of the counter cell to survive the change of ticks second. The end result is that events counted in the previous second would be transferred to the next second despite the reset, and cause unmerited rate check trigger. At very least, the function annotation should contain a warning to use it only for informational messages.