From owner-svn-src-all@FreeBSD.ORG Mon Feb 9 21:45:42 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 E68A5BC0; Mon, 9 Feb 2015 21:45:42 +0000 (UTC) Received: from lakerest.net (lakerest.net [162.235.35.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lakerest.net", Issuer "Stewart" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D9EC3B6; Mon, 9 Feb 2015 21:45:42 +0000 (UTC) Received: from rrss-MacBook-Air.local (173.64-138-239-net.sccoast.net [64.138.239.173]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id t19LZgdc003632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Feb 2015 16:35:43 -0500 (EST) (envelope-from rrs@freebsd.org) Message-ID: <54D92A7A.9000300@freebsd.org> Date: Mon, 09 Feb 2015 16:45:30 -0500 From: randall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: svn commit: r278472 - in head/sys: netinet netinet6 References: <201502091928.t19JSC5P066293@svn.freebsd.org> <1903622.i3cFFNVYcL@ralph.baldwin.cx> In-Reply-To: <1903622.i3cFFNVYcL@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@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: Mon, 09 Feb 2015 21:45:43 -0000 On 2/9/15 3:11 PM, John Baldwin wrote: > Eh, I looked at it, but I really, really don't like it. I think > callout_init_*() should be preferred to CALLOUT_MPSAFE whenever possible as it > is less race-prone. I think this should probably be fixed by adding Hans' > callout_drain_async() instead, though this is fine as a temporary workaround. I know you did not like it, and I think in principle I agree with you that a new callout_drain_async() needs to be introduced to the KPI for callout. That all being said in this one case, I do think the right immediate fix (until thats ready) was to make it MPSAFE like I did. In this particular instance init'ing with the lock was exactly the wrong thing to do with the reference counting that was going on. Yes, we need to get the drain_async.. but that will take more time and more poking at the callout system to make sure its solid before we start switching things to use it. And this I think was panic'ing a *lot* of systems.. R >