> > - as far as you use VOPs in the framework, i guess you need some kind of
> >   locking rules.
> 
> i only use VOP_GETATTR(). or..?

then "you can call this function only when it's safe to call VOP_GETATTR."

> > - fileassoc_file_delete in sys_unlink:
> > 	- is it intended to call it whenever a link to a file is removed?
> 
> no, and that's a valid concern for the veriexec hook too. perhaps we
> should check the link count? any suggestion?

checking the link count in filesystem independent code is a somewhat
new concept for us.  i'm not sure if it's a good idea.

> > 	- i don't think nd.ni_vp is always valid after VOP_REMOVE.
> 
> i tried to place it in a spot where it will only be entered if the file
> was removed. any suggestion?

let's define "file was removed" first.

	1. whenever link count is decremented.
	2. when link count reaches 0.  ie. disappeared from namespace.
	3. when the last reference is closed after #2.
	4. other?

i think #3 is reasonable, and if so, sys_unlink is not a right place.

> > - please make fileassoc.h minimal.
> > 	- unexport functions and structures which aren't necessary to be
> > 	  exported.
> > 	  eg. fileassoc_init (use static initialization or RUN_ONCE),
> > 	  fileassoc_file_lookup, fileassoc_hash_entry.
> 
> why not export fileassoc_file_lookup? it's used in the veriexec code.

where?  isn't it fileassoc_lookup?

YAMAMOTO Takashi