Date: Sat, 13 Feb 1999 13:50:24 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: hackers@FreeBSD.ORG Subject: Re: VOP_REMOVE() rules for freeing a_cnp ? Message-ID: <Pine.BSF.4.05.9902131337370.351-100000@herring.nlsystems.com> In-Reply-To: <199902130857.AAA14274@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 13 Feb 1999, Matthew Dillon wrote: > I can't make heads or tails of the VOP_REMOVE() rules for freeing > a_cnp. > > The man page doesn't say anything about having to free cnp. > > ufs_remove() doesn't bother. > > nfs_remove() always frees it. > > And the unlink() system call seems to expect the cnp to be freed > by the VOP_REMOVE() function. > > Typically the rule for freeing a struct componentname in a VOP > routine is 'free it if you return an error, otherwise only free > it if the SAVESTART flag is not set in cn_flags'. > > I would appreciate it if a VFS guru could look at this junk and > tell me whos right. I'm sure that someone changed the semantics for who frees the pathnames and who releases the vnodes during the 3.0 development cycle but I can't quite remember who (Mike someone maybe, not Mike Smith). I think that the intention was to always free the path and release the vnodes in the caller, not in the filesystem (which was supposed to make it easier to write layers). I have a vague recollection that VOP_RENAME was the only one which wasn't changed since it does some wildly complicated things with its vnodes. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 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?Pine.BSF.4.05.9902131337370.351-100000>