Date: Thu, 19 Jan 2006 16:09:40 -0500 From: John Baldwin <jhb@freebsd.org> To: Alan Cox <alc@cs.rice.edu> Cc: alc@freebsd.org, freebsd-current@freebsd.org, Suleiman Souhlal <ssouhlal@freebsd.org>, Kris Kennaway <kris@obsecurity.org> Subject: Re: System call munmap returning with the following locks held: Giant Message-ID: <200601191609.43529.jhb@freebsd.org> In-Reply-To: <20060119203833.GC7599@cs.rice.edu> References: <20060118070549.GA617@xor.obsecurity.org> <200601191114.27075.jhb@freebsd.org> <20060119203833.GC7599@cs.rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601191609.43529.jhb>