From owner-svn-src-all@FreeBSD.ORG Thu May 12 11:59:19 2011 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E53CF1065677; Thu, 12 May 2011 11:59:19 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id ED9588FC0C; Thu, 12 May 2011 11:59:17 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA25529; Thu, 12 May 2011 14:59:16 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DCBCB93.200@FreeBSD.org> Date: Thu, 12 May 2011 14:59:15 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <201105091734.p49HY0P3006180@svn.freebsd.org> <20110512024956.996cd973.stas@FreeBSD.org> <4DCBB9EE.8070809@FreeBSD.org> <20110512035522.e42b379c.stas@FreeBSD.org> <4DCBBCBE.5020004@FreeBSD.org> <4DCBBEF5.4090004@FreeBSD.org> <4DCBC73D.9070006@FreeBSD.org> In-Reply-To: <4DCBC73D.9070006@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: src-committers@FreeBSD.org, neel@FreeBSD.org, svn-src-all@FreeBSD.org, Stanislav Sedov , svn-src-head@FreeBSD.org, Jung-uk Kim Subject: Re: svn commit: r221703 - in head/sys: amd64/include i386/include x86/isa x86/x86 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 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: Thu, 12 May 2011 11:59:20 -0000 on 12/05/2011 14:40 John Baldwin said the following: > > Hmmm, this might be interesting. I think you want to always wait for this though > even if you have a teardown function. > I think so too. In fact I have that change in my private tree, but was still waiting (a few months) for someone to enlighten why the code is the way it is. It seems that the problematic case is when both of the following are true: curcpu is not in the target cpu set and teardown function is not a "no rendevous" one [spelling mistake preserved :-)]. -- Andriy Gapon