Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Nov 1999 00:03:59 +0100
From:      Eivind Eklund <eivind@FreeBSD.org>
To:        fs@FreeBSD.org
Subject:   namei() and freeing componentnames
Message-ID:  <19991112000359.A256@bitbox.follo.net>

next in thread | raw e-mail | index | archive | help
I would like to make this reflexive - "symmetrical" allocation and
free, like it presently is supposed to be with SAVESTART (but isn't -
there are approximately one billion bugs in the code).

I suspect that for some filesystems (though none of the present ones),
it might be necessary to do more than a
zfree(namei_zone,cnp->cn_pnbuf) in order to free up all the relevant
data.  In order to support this, we'd have to introduce a new VOP -
tentatively called VOP_RELEASEND().  Unfortunately, this comes with a
performance penalty.

As we presently do not need this capability, I am thinking of
"faking" VOP_RELEASEND() - make it into a macro similar to this:
#define VOP_RELEASEND(vp, cnp) do {			\
	(void)(vp);   /* Do side effects of (vp) */	\
	zfree(namei_zone, (cnp)->cn_pnbuf;		\
} while (0)

This is somewhat vile, but has the advantage of keeping the code ready
for the real VOP_RELEASEND(), and not loosing performance until we
actually get some benefit out of it.

Do the rest of you consider it too vile to do, or is it an OK
tradeoff?  (Personally, I consider it an OK tradeoff.)

It also allows an evil hack:
The NFS code is rather incestuous with the VFS system, in order to
minimize the amount of cached data during NFS requests.  One side of
this is that it seems to throw away the vnode we'd like to use for
VOP_RELEASEND() - before it wants to throw away the componentname.
With the macro, NFS could use VOP_RELEASEND(NULL, <stuff>); for the
time being, crashing in a very obvious way when we find we need to
introduce the actual VOP.  This avoids re-structuring the NFS code
until we actually get benefits from VOP_RELEASEND.

Is it too evil?  I'm of two minds - I don't like messing more than
necessary with the NFS code (and isn't sure I could do the messing
without performance impact), but I'm not exactly ecstatic about the
hack, either.

I've got first pass patches for the above (not tested, not compiled,
not done the three different forms of review for errors I'm planning
to do).

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?19991112000359.A256>