cache_purge > cache_zap segmentation fault

[Ali Bahar]

Hi dude,
(not quite sure which'd be your first name. 'phk' is how I remember
you by!)



On Thu, May 08, 2003 at 08:08:40PM +0200, Poul-Henning Kamp wrote:
> In message <20030508140210.B26126 at internetDog.org>, Ali Bahar writes:

> >I still need to understand the difference between a vnode's
> >v_cache_src and v_cache_dst (IOW, a namecache's nc_src and nc_dst),
> 
> One is for the chain which a (directory) vnode sources, the other
> is the chain where the (any type) vnode hangs from it's parent
> directory.

Hmm. Forgive me, but I went over the above sentence 20 times, and I'm
still not sure.

Given the vnode for /usr/src, 

  - is its v_cache_dst a linked list of namecache entries for /usr, 
  - &  its v_cache_src a linked list of namecache entries for /usr/src/sys ?

Or vice versa? Or neither?
Why would there be a _chain_ of namecache nodes for a file's parent? I
assume that symbolic links are involved (from another dir to this file).

Would you know if the 5.0 modifications could fix this problem?  My
reading of the problem is: As a new file/dir is being accessed, a new
vnode is obtained thru getnewvnode.  But vnodes are recycled, and so
the 'new' vnode has to be cleaned up. This means that all its old
associations/resources have to be deleted. What is happening in
cache_zap, is that its "source vnode list" of namecache entries is
being deleted.  In the deletion, it comes across a dangling/corrupt
namecache node.


Thank you very much for your help. Much appreciated.
regards,
ali
-- 
             Jesus was an Arab.