From owner-freebsd-current@FreeBSD.ORG Thu Jan 19 21:09:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0952D16A41F; Thu, 19 Jan 2006 21:09:03 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id B185943D48; Thu, 19 Jan 2006 21:08:57 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 6479782 for multiple; Thu, 19 Jan 2006 16:09:55 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0JL8pSZ064868; Thu, 19 Jan 2006 16:08:53 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Alan Cox Date: Thu, 19 Jan 2006 16:09:40 -0500 User-Agent: KMail/1.9.1 References: <20060118070549.GA617@xor.obsecurity.org> <200601191114.27075.jhb@freebsd.org> <20060119203833.GC7599@cs.rice.edu> In-Reply-To: <20060119203833.GC7599@cs.rice.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601191609.43529.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1245/Wed Jan 18 11:57:44 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED, SUBJECT_EXCESS_QP autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: alc@freebsd.org, freebsd-current@freebsd.org, Suleiman Souhlal , Kris Kennaway Subject: Re: System call munmap returning with the following locks held: Giant 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 Jan 2006 21:09:03 -0000 On Thursday 19 January 2006 15:38, Alan Cox wrote: > On Thu, Jan 19, 2006 at 11:14:24AM -0500, John Baldwin wrote: > [snip] > > > Are you really sure the object's type can change or does the caller of > > vm_object_deallocate() hold some sort of reference or what not that > > prevents the type from changing? > > My recollection is that the object does not change type until all of > the references have been drained and it is about to be freed by > vm_object_terminate(). At the point where the type check is being > performed, the caller should hold a reference on the object. Thus, > the type should not be changing. > > That said, an unexpected type change still strikes me as the most > plausible cause. > > Is there a test that easily reproduces this problem? Kris Kenneway has one involving NFS. My first patch was bogus in that I missed the magic with vm_object_vndeallocate(), so I think the only way Kris was seeing it was by the race of the type changing. I've sent him an updated patch like the one in my previous message that used a restart loop to lock Giant if it was needed. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org