Date: Thu, 1 Feb 2007 18:38:27 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Guy Helmer <ghelmer@palisadesys.com> Cc: freebsd-stable@freebsd.org Subject: Re: 6.2 amd64 panic: lockmgr: thread 0xffffff009f9fd000, not exclusive lock holder 0xffffff003961c000 unlocking Message-ID: <20070201163826.GI56152@deviant.kiev.zoral.com.ua> In-Reply-To: <45C20F00.4010900@palisadesys.com> References: <45C0C749.1040300@palisadesys.com> <45C20F00.4010900@palisadesys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--sl5MdczEF/OU2Miu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Feb 01, 2007 at 10:02:08AM -0600, Guy Helmer wrote:
> Guy Helmer wrote:
> >Does this make sense to anyone (it doesn't to me - procfs_doprofile=20
> >simply locks, calls vn_fullpath, and unlocks)? I was trying to track=20
> >down a hang by running a system under stress, and instead got this=20
> >panic as a result of a process running a perl script that looks=20
> >through /proc/; it occurred on a very busy system with lots of process=
=20
> >churn.
> Does this change to src/sys/fs/procfs.c make sense? From my reading, it=
=20
> is possible for vn_lock(9) to fail...
>=20
> Index: procfs.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /home/ncvs/src/sys/fs/procfs/procfs.c,v
> retrieving revision 1.12.2.1
> diff -u -r1.12.2.1 procfs.c
> --- procfs.c 14 Jun 2006 21:20:39 -0000 1.12.2.1
> +++ procfs.c 1 Feb 2007 15:19:30 -0000
> @@ -69,8 +69,11 @@
> {
> char *fullpath =3D "unknown";
> char *freepath =3D NULL;
> + int err;
>=20
> - vn_lock(p->p_textvp, LK_EXCLUSIVE | LK_RETRY, td);
> + if ((err =3D vn_lock(p->p_textvp, LK_EXCLUSIVE | LK_RETRY, td)) !=3D 0)=
{
> + return (err);
> + }
> vn_fullpath(td, p->p_textvp, &fullpath, &freepath);
> VOP_UNLOCK(p->p_textvp, 0, td);
> sbuf_printf(sb, "%s", fullpath);
vn_lock with LK_EXCLUSIVE|LK_RETRY flags combination shall not fail. It sho=
uld
return even dead vnodes locked.
I suspect that in fact this is race with exec(). Could you reproduce the
panic ? And then, with this patch ?
Index: fs/procfs/procfs.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /usr/local/arch/ncvs/src/sys/fs/procfs/procfs.c,v
retrieving revision 1.14
diff -u -r1.14 procfs.c
--- fs/procfs/procfs.c 5 Jun 2006 16:41:27 -0000 1.14
+++ fs/procfs/procfs.c 1 Feb 2007 16:37:43 -0000
@@ -69,10 +69,12 @@
{
char *fullpath =3D "unknown";
char *freepath =3D NULL;
+ struct vnode *textvp;
=20
- vn_lock(p->p_textvp, LK_EXCLUSIVE | LK_RETRY, td);
- vn_fullpath(td, p->p_textvp, &fullpath, &freepath);
- VOP_UNLOCK(p->p_textvp, 0, td);
+ textvp =3D p->p_textvp;
+ vn_lock(textvp, LK_EXCLUSIVE | LK_RETRY, td);
+ vn_fullpath(td, textvp, &fullpath, &freepath);
+ VOP_UNLOCK(textvp, 0, td);
sbuf_printf(sb, "%s", fullpath);
if (freepath)
free(freepath, M_TEMP);
--sl5MdczEF/OU2Miu
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFFwheCC3+MBN1Mb4gRAvyqAKDwMF58xF8t0As48qCR/Gi9eSwvTgCeIjUE
v3EVmqGv41JvGjiOa5HJCgM=
=Zuk4
-----END PGP SIGNATURE-----
--sl5MdczEF/OU2Miu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070201163826.GI56152>