System call munmap returning with the following locks held: Giant

John Baldwin jhb at
Thu Jan 19 05:05:27 PST 2006

On Wednesday 18 January 2006 08:31 pm, Suleiman Souhlal wrote:
> Hi,
> John Baldwin wrote:
> > I sent this to you on IRC, but for the archives, here's a possible fix. 
> > It looks like vm_object_deallocate() never unlocks Giant if it locks it,
> > and the leak would only happen if mpsafevfs=0 or you are using a non-safe
> > filesystem:
> The real problem is that vm_object_deallocate() doesn't expect the
> object's type to change if it sees it's a vnode, when it's not holding
> the object lock:
>      /*
>       * In general, the object should be locked when working with
>       * its type.  In this case, in order to maintain proper lock
>       * ordering, an exception is possible because a vnode-backed
>       * object never changes its type.
>       */
>       vfslocked = 0;
>       if (object->type == OBJT_VNODE) {
>           struct vnode *vp = (struct vnode *) object->handle;
>           vfslocked = VFS_LOCK_GIANT(vp->v_mount);
>       }
>       VM_OBJECT_LOCK(object);
>       if (object->type == OBJT_VNODE) {
>           vm_object_vndeallocate(object);
>           VFS_UNLOCK_GIANT(vfslocked);
>           return;
>        }
> The comment is actually wrong, and the object's type can change to
> OBJT_DEAD when the corresponing vnode gets freed, so maybe you might
> want to change it.

Well, that's not the cause of Kris' panic at all (the function really is not 
ever dropping Giant).  If the object does change to OBJT_DEAD after Giant is 
acquired then some of the MPASS()'s I added might fail I think.  I'm not sure 
if that's all that has to be done to fix the problem you are concerned about.

John Baldwin <jhb at>  <><
"Power Users Use the Power to Serve"  =

More information about the freebsd-current mailing list