vn_fullpath: 0xc85e24a0 is not locked but should be
Jun Kuriyama
kuriyama at imgsrc.co.jp
Fri Dec 12 05:37:46 PST 2003
At Thu, 11 Dec 2003 23:14:50 -0500 (EST),
Robert Watson wrote:
> Ah, you're still runing with the VFS lock debugging :-). Indeed, it looks
> like a vn_lock() and unlock of p->p_textvp is missing in
> procfs_doprocfile(), even though that likely would violate the VFS lock
> order. The attached (untested) patch might well fix it, but might not be
> right -- I'm not sure that curthread holds a valid reference to
> p->p_textvp that can't evaporate during these operations. I'm not sure
> the proc reference stuff protects us properly here, but John would know
> (CC'd).
>
> Index: procfs.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/fs/procfs/procfs.c,v
> retrieving revision 1.9
> diff -u -r1.9 procfs.c
> --- procfs.c 17 Apr 2003 22:12:12 -0000 1.9
> +++ procfs.c 12 Dec 2003 04:13:10 -0000
> @@ -70,7 +70,9 @@
> char *fullpath = "unknown";
> char *freepath = NULL;
>
> + 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);
> sbuf_printf(sb, "%s", fullpath);
> if (freepath)
> free(freepath, M_TEMP);
Okay, I'll wait without DEBUG_VFS_LOCKS until fix is committed.
At Thu, 11 Dec 2003 23:15:03 -0700 (MST),
M. Warner Losh wrote:
> : # Why I got so many panics? :-(
>
> Because after you get 10,000 of them, you are forced to serve on core
> :-)
I hope I won't get more. :-)
--
Jun Kuriyama <kuriyama at imgsrc.co.jp> // IMG SRC, Inc.
<kuriyama at FreeBSD.org> // FreeBSD Project
More information about the freebsd-current
mailing list