Date: Thu, 25 Nov 1999 18:22:00 +0100 From: Eivind Eklund <eivind@FreeBSD.ORG> To: Terry Lambert <tlambert@primenet.com> Cc: fs@FreeBSD.ORG Subject: Re: namei() and freeing componentnames Message-ID: <19991125182159.B602@bitbox.follo.net> In-Reply-To: <199911241819.LAA19803@usr08.primenet.com>; from tlambert@primenet.com on Wed, Nov 24, 1999 at 06:19:52PM %2B0000 References: <19991112000359.A256@bitbox.follo.net> <199911241819.LAA19803@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 24, 1999 at 06:19:52PM +0000, Terry Lambert wrote: > You say that you want it to be reflexive and symmetrical; path > name buffers are allocated by the VFS consumer. To achieve > this goal, they must also be deallocated by the VFS consumer. I have a series of progressive patches towards this goal available at http://www.freebsd.org/~eivind/ None of these are expected to in any way be near working, and I misread the namei() code enough that there are a bunch of VOP_RELEASENDs that need to be removed. Right now, after seeing how much chaos the VOP_RELEASEND stuff turned into and how many places other code is repeated, I'm tempted to go for a NDFREE() which can free struct nameidata, *including vrele/vput'ing aquired vp*, and which takes flags to indicate if it is to leave some resources behind. Fortunately, I now have diffs most of the places where this would be needed, and have worked with the code in those areas recently, so it hopefully won't be that much work to convert the diffs to this model (which would mean that the VOP_RELEASEND that is in those patches disappear). > One of the largest barriers to transaction using VFSs in BSD > at this point is that the VOP_ABORTOP() frees the path name > buffer, and it should not. I've noticed :) In the present patches, I am plain slaying VOP_ABORTOP(), on the basis of it not being used for anything anymore (all it did in all filesystems we have was to free the pathname), and intended to have it re-introduced correctly when/if we get a transactional FS. I was intending to discuss this once I was at a point where patches were actually runnable (along with other decisions I've made while actually hacking the code), though feel free to come with views on it (since you've brought it into the conversation). I'll get back to the rest of your message (and the other one) later; I just wanted to give at least some indication that I am not a black hole. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991125182159.B602>