cache_purge > cache_zap segmentation fault

Poul-Henning Kamp phk at
Thu May 8 12:12:57 PDT 2003

In message <20030508150341.B28906 at>, Ali Bahar writes:

>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 ?

If you look at the definition in sys/sys/vnode.h, it actually is pretty
clear from that:

struct vnode {
        LIST_HEAD(, namecache) v_cache_src;     /* c Cache entries from us */
        TAILQ_HEAD(, namecache) v_cache_dst;    /* c Cache entries to us */

So imagine this name cache entry:

	directory vnode:	vnode of "/usr/src"	[vnode#1]
	name			"sys"
	destination vnode:	vnode of "/usr/src/sys"	[vnode#2]

This name cache entry will be a member of the "v_cache_src" LIST from
vnode#1, and of the v_cache_dst TAILQ for vnode#2

Other entries on vnode#1's ..._src LIST will be for /usr/src/bin,
/usr/src/etc and so on.

The thing you have to remember is that one vnode can have multiple names
due to hard links.  If it could have only one, the TAILQ would not
be necessary.

In this case there will be no other elements on vnode#2's TAILQ
since we do not allow hardlinks to directories.

>Would you know if the 5.0 modifications could fix this problem?

I'm not sure I know what the problem is, I just stumbled on your
email midthread I think...

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

More information about the freebsd-hackers mailing list