From owner-freebsd-sparc64@FreeBSD.ORG Wed Mar 2 15:20:52 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C26FD16A4CE for ; Wed, 2 Mar 2005 15:20:52 +0000 (GMT) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id A557443D55 for ; Wed, 2 Mar 2005 15:20:51 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 26109 invoked from network); 2 Mar 2005 15:20:51 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 2 Mar 2005 15:20:51 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j22FKeYM081583; Wed, 2 Mar 2005 10:20:44 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Bosko Milekic Date: Wed, 2 Mar 2005 10:16:36 -0500 User-Agent: KMail/1.6.2 References: <20050301000436.GA33346@xor.obsecurity.org> <20050301231438.GA25573@xor.obsecurity.org> <20050301234937.GA19502@technokratis.com> In-Reply-To: <20050301234937.GA19502@technokratis.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503021016.36953.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Kris Kennaway cc: sparc64@FreeBSD.org cc: rwatson@FreeBSD.org cc: freebsd-sparc64@FreeBSD.org cc: net@FreeBSD.org cc: Bosko Milekic cc: bmilekic@FreeBSD.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 15:20:52 -0000 On Tuesday 01 March 2005 06:49 pm, Bosko Milekic wrote: > You know, the more and more we run into these problems specific to how > reference counting is performed, I keep wondering whether some cleverly > defined macros for dealing with common reference counting operations > would be worthwhile. I'm not saying "introduce a refcount_t type and a > full-blown abstraction," but some template-like stuff might be useful. > It took a while just to get the refcount decrement on free path free of > races on SMP, and that's only in the mbuf code. Yeah, I have those simple refcount_foo() macros that operate on ints that would work for here and things like ucreds. Being macros, each arch can override if they have a better native instruction (xadd on x86, fetchadd on ia64, etc.) > -Bosko > > On Tue, Mar 01, 2005 at 03:14:38PM -0800, Kris Kennaway wrote: > > On Tue, Mar 01, 2005 at 06:04:27PM -0500, Bosko Milekic wrote: > > > This does not appear to explain the livelock. > > > > alc and dwhite tracked it down to a missing volatile causing gcc to > > mis-optimize the loop: > > > > - cnt = *(m->m_ext.ref_cnt); > > + cnt = *(volatile u_int *)(m->m_ext.ref_cnt); > > > > I'm currently testing that. > > > > Kris -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org