Date: Fri, 12 Dec 2003 10:35:35 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: kuriyama@imgsrc.co.jp Cc: freebsd-current@FreeBSD.org Subject: Re: vn_fullpath: 0xc85e24a0 is not locked but should be Message-ID: <200312121835.hBCIZZeF058658@gw.catspoiler.org> In-Reply-To: <7mwu9217j0.wl@black.imgsrc.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 Dec, Jun Kuriyama wrote: > 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. DEBUG_VFS_LOCKS is quite usable as long as you don't run find, tar, etc. that traverses procfs.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200312121835.hBCIZZeF058658>