System call munmap returning with the following locks held: Giant

John Baldwin jhb at
Thu Jan 19 13:09:03 PST 2006

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 at>  <><
"Power Users Use the Power to Serve"  =

More information about the freebsd-current mailing list