Date: Sun, 14 Feb 1999 00:54:49 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: hackers@FreeBSD.ORG Subject: Re: NFS VOP calls (was Re: Lots of "panic: vrele: negative ref cnt" ) Message-ID: <199902140054.RAA00998@usr06.primenet.com> In-Reply-To: <199902130941.BAA14698@apollo.backplane.com> from "Matthew Dillon" at Feb 13, 99 01:41:37 am
next in thread | previous in thread | raw e-mail | index | archive | help
> It looks like there are a number of problems, but the one reported > above is the only one that gets 'hit'. The NFS code pretty much > ignores the VOP semantics for freeing path name elements but it > just happens to get called with the path name (cnp) structure flagged > the way it happens to decide to use it, so it works. But there is > probably some leakage of NAMEI nodes when NFS errors occur. > > I've only committed the fix for the vrele panic to -3.x. The fix > to the rest of the mis-used path elements has been committed to -4.x > and will not be backported to -3.x until after the release since > I'm not 100% sure those other fixes are correct. -3.x should not be > detrimentally effected by not having the other junk in. > > Confused yet? :-) Beware. It is very easy to introduce a memory leak/multiple free error in the NFS server case. I highly recommend you use my test framework for this; DFR has a copy, and someone brought it up to date. Basically, it allows you to perform a list of operations (system calls) in a test framework, and track the resulting amount of various kernel allocations (as reported by vmstat). The framework comes with code to look at the NAMEI code in particular, since that's excatly the place I introduces a leak in the NFS code in my initial set of "nameifree()" patches. >From the top down, the NFS server is, like the system call layer, a consumer of VFS interfaces. As a result of this, the NFS server does local allocation of path buffers through it's own method of obtaining them, expecting the callee to delete them (in some cases, it, in fact, cretes them for the express purpose of having them there when the callee goes to delete them). If you are *really* interested in cleaning up and speeding this code, FreeBSD really needs the generic idea of a "counted object queue", with high and low watermarks, for drain/fill, and should keep around a preallocated list of path name buffers that are caller alloc/free, instead of allocating via NDINIT (or in NFS) and deallocating everywhere, at random. This would also be somewhat a move in the per CPU pool direction, as well as a move in the direction of doing page starvation avoidance, rather than page starvation detection and correction (you could consider the low watermark point of the object type queue to be your "reserve" from the page reserve design). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902140054.RAA00998>