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

next in thread | previous in thread | raw e-mail | index | archive | help
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.=
=20
> > It looks like vm_object_deallocate() never unlocks Giant if it locks it,
> > and the leak would only happen if mpsafevfs=3D0 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 =3D 0;
>       if (object->type =3D=3D OBJT_VNODE) {
>           struct vnode *vp =3D (struct vnode *) object->handle;
>           vfslocked =3D VFS_LOCK_GIANT(vp->v_mount);
>       }
>       VM_OBJECT_LOCK(object);
>       if (object->type =3D=3D 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 no=
t=20
ever dropping Giant).  If the object does change to OBJT_DEAD after Giant i=
s=20
acquired then some of the MPASS()'s I added might fail I think.  I'm not su=
re=20
if that's all that has to be done to fix the problem you are concerned abou=
t.

=2D-=20
John Baldwin <jhb@FreeBSD.org> =A0<>< =A0http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org



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