From owner-freebsd-fs@FreeBSD.ORG Wed Dec 2 16:53:07 2009 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A757B106566B for ; Wed, 2 Dec 2009 16:53:07 +0000 (UTC) (envelope-from lists@mschuette.name) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [IPv6:2001:638:807:3a:20d:56ff:fefd:1183]) by mx1.freebsd.org (Postfix) with ESMTP id 37E398FC16 for ; Wed, 2 Dec 2009 16:53:07 +0000 (UTC) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 35751502448 for ; Wed, 2 Dec 2009 17:53:06 +0100 (CET) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id YPhDuIXdN6Ij for ; Wed, 2 Dec 2009 17:52:40 +0100 (CET) Received: from dagny.mschuette.name (cl-485.dus-01.de.sixxs.net [IPv6:2a01:198:200:1e4::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTPSA id B5017502437 for ; Wed, 2 Dec 2009 17:52:40 +0100 (CET) Message-ID: <4B169B57.1070603@mschuette.name> Date: Wed, 02 Dec 2009 17:52:39 +0100 From: =?UTF-8?B?TWFydGluIFNjaMO8dHRl?= User-Agent: Thunderbird 2.0.0.23 (X11/20090908) MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org References: <4B09EDB2.7020002@mschuette.name> <20091124132357.GA1941@tops.skynet.lt> In-Reply-To: <20091124132357.GA1941@tops.skynet.lt> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: [nullfs] [panic] null with unref'ed lowervp X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 16:53:07 -0000 Gleb Kurtsou wrote: > In my understanding null_checkvp assumptions doesn't hold in null_lock > and null_unlock. So I'd suggest you running without DIAGNOSTIC or try > attached patch instead. Thanks. I installed the patch now. Because I already reduced the number of nullmounts I cannot really 'test' it but I will write in case I see the issue again. -- Martin