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>