From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 00:04:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4404106567A for ; Thu, 19 Aug 2010 00:04:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 919CE8FC14 for ; Thu, 19 Aug 2010 00:04:55 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAM4RbEyDaFvO/2dsb2JhbACDGJ4wrkySIIEigyJzBIlt X-IronPort-AV: E=Sophos;i="4.56,230,1280721600"; d="scan'208";a="90991500" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 18 Aug 2010 20:04:52 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 94AF4B3F0A; Wed, 18 Aug 2010 20:04:54 -0400 (EDT) Date: Wed, 18 Aug 2010 20:04:54 -0400 (EDT) From: Rick Macklem To: pluknet Message-ID: <699547258.794609.1282176294566.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [137.207.32.112] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (zclient/6.0.7_GA_2476.RHEL4) Cc: Kostik Belousov , FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 00:04:55 -0000 > On 18 August 2010 12:07, pluknet wrote: > > On 17 August 2010 20:04, Kostik Belousov wrote: > > > >> > >> Also please take a note of the John' suggestion to use the taskqueue. > > > > I decided to go this road. Thank you both. > > Now I do nfs buildkernel survive and prepare some benchmark results. > > > I'm away from home, so I can only do email and haven't looked at the patch, but I think you might want to consider avoiding the malloc() failure by calling malloc(... M_WAITOK); before grabbing the mutex. Then, set the pointer to NULL if you use it and free it at the end (I tend to test for non-NULL before calling free(), but others have pointed out that this isn't necessary.) I believe this is called "Dykstra's technique", although I used it a lot before I found out it had been published. I think handling the case where malloc() fails correctly could be difficult which is why I suggested the above. Good luck with the patch, rick