Re: Kernel panic on fs mkmount

On Fri, 2003-05-16 at 18:12, Chaskiel M Grundman wrote:
> --On Friday, May 16, 2003 14:27:53 -0400 "David E. Cross"
> <[email protected]> wrote:
> 
> > My _hack_  ( a nasty one), is to call vref() on the
> > link itself and pass it back as _both_ the linkvp and the directoryvp. 
> This shouldn't be necesary. We can either
> 
> 1) create a variation of afs_symlink that returns the vcache object that it
> always creates on success (and have afs_symlink itself be a wrapper around
> the new function that also frees the reference on the returned vcache)
> 2) call afs_lookup on success. That ought to be nearly "free", unless the
> directory was not previously cached.
> 
> I can't test freebsd stuff right now, since I lent my freebsd-running box
> to someone who's hardware died.
No, it shouldn't be necessary, but I think you are misunderstanding the
problem (well, my description of the problem and solution).  The current
implementation _does_ return the vcache of the object that was just
created, that is the vp.  the FreeBSD syscall for symlink expects that
_and_ vpd, the vnode to the directory that the symlink was created in. 
This information is already kept in the layer one up from afs_symlink. 
What I suspect happened is that some OS didn't free the vpd and thus
caused leaks, then it was wrapped.. now we are talking about wrapping
the wrap.  I'd like to see either:
1) An #ifdef, or equivalent functionality, to have it not vrele() the
vpd in the first place, and pass it back as such.
2) Modify FreeBSD to do a check on vpd, if it is "NULL", then don't do
anything.

2 is easier, but I am unsure of VFS interactions on this, changing the
API, etc.  It _should_ be safe given what I have seen in creating this
hack in the first place.  As I recall 1 involved changing a bit more
than I was comfortable with at the time.  Since then I've mostly
replaced the AFS VN layer with something that is cleaner and much more
efficient, so these hacks are delving back in my memory aways.

-- 
David E. Cross