Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Jan 2006 17:31:00 -0800
From:      Suleiman Souhlal <ssouhlal@FreeBSD.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-current@freebsd.org, current@freebsd.org, Kris Kennaway <kris@obsecurity.org>
Subject:   Re: System call munmap returning with the following locks held:	Giant
Message-ID:  <43CEEBD4.3060604@FreeBSD.org>
In-Reply-To: <200601181652.59407.jhb@freebsd.org>
References:  <20060118070549.GA617@xor.obsecurity.org> <200601181652.59407.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

-- Suleiman



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43CEEBD4.3060604>