From owner-svn-src-all@FreeBSD.ORG Wed Jan 21 08:51:09 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A17D4AB for ; Wed, 21 Jan 2015 08:51:09 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86326D26 for ; Wed, 21 Jan 2015 08:51:08 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t0L8p0xC035613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2015 10:51:00 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0L8p0xC035613 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0L8p08Z035612; Wed, 21 Jan 2015 10:51:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 21 Jan 2015 10:51:00 +0200 From: Konstantin Belousov To: Hans Petter Selasky Subject: Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys Message-ID: <20150121085100.GQ42409@kib.kiev.ua> References: <54BDD9E1.6090505@selasky.org> <20150120075126.GA42409@kib.kiev.ua> <20150120211137.GY15484@FreeBSD.org> <54BED6FB.8060401@selasky.org> <54BEE62D.2060703@ignoranthack.me> <54BEE8E6.3080009@ignoranthack.me> <54BEEA7F.1070301@ignoranthack.me> <54BF640B.6000700@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BF640B.6000700@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Adrian Chadd , "src-committers@freebsd.org" , "K. Macy" , Jason Wolfe , "svn-src-all@freebsd.org" , sbruno@freebsd.org, Gleb Smirnoff , "svn-src-head@freebsd.org" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 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: Wed, 21 Jan 2015 08:51:09 -0000 On Wed, Jan 21, 2015 at 09:32:11AM +0100, Hans Petter Selasky wrote: > On 01/21/15 00:53, Sean Bruno wrote: > > Unkown to me. Nor am I aware of anyone else who ever hit our panics > > either. Our environment, and the failure, was only seen in the Intel > > 10GE space (ixgbe). This is an artifact of our use cases, and hasn't > > been expanded nor tested in our environment with other vendor interfaces. > > > > sean > > Hi, > > I've seen this with Mellanox hardware when running some special tests, > but not during regular use yet. That was the reason for going into the > callout subsystem in the first place. 40GE. > > Also I would like to mention during the heat of this discussion, that > during X-mas this year, I had a very heavy discussion with Attilio and a > few other FreeBSD developers, who's name was on a patch (r220456) that > changed how the return value of "callout_active()" works. > "callout_active()" is heavily used inside the TCP stack and what was > found is there is a potential race related to migrating the callout from > one CPU to the other, which in turn might give other symptoms than a > spinlock hang. > > FYI: > > https://svnweb.freebsd.org/base?view=revision&revision=225057 > > Cite: "If the newly scheduled thread wants to acquire the old queue it > will just spin forever." > > This description reminds me very much of what "Jason Wolfe", others and > myself have seen. > > Konstantin, you're responsible for r220456 (Approved by: kib). I would I definitely do not see anything related to my freefall login in the log message for r220456, nor I participated in any way in the work which lead to that revision. If you mean r225057, note that approval by re != review. > like to ask what investigation you did to ensure that you solved the > problem as described in the commit message and didn't introduce a new one? > > In r220456 the "callout_reset_on()" function was changed in a way that > directly conflicts with how the TCP stack works, by not always ensuring > that "callout_active()" returns non-zero after a callout is restarted! > See return at line 821: > > > https://svnweb.freebsd.org/base/head/sys/kern/kern_timeout.c?revision=225057&view=markup&pathrev=225057#l821 > > Kib: Any comments? With the re hat on, explanation for the proposed commit looked reasonable, and committer provided enough evidence that change got adequate testing. Since change fixed a bug, and this is exactly what re wants to see during release cycle, I see no reason why commit should be denied.