On Wed, 16 Apr 2003, Matthias Drochner wrote:

>
> Now that I got sick of the box dropping into DDB during reboot almost
> everytime after I did a system build, I looked into the issue.
>
> The problem is that the directory vnode used by nfs_removeit() is not
> necessarily valid anymore.
> If the directory vnode got cleaned up between the sillyrename() and the
> inactive(), one gets a panic.
>
> This is a problem in 2 cases:
> -on heavy system load (PR kern/9491) -- I couldn't reproduce this case,
>  but it looks obvious
> -during shutdown (PR kern/9326, kern/11284) -- vflush() just works through
>  a list of associated vnodes, and it happens that a directory vnode is
>  vgone'd before the sillyrename'd files within it
>
> So there are 3 approaches coming to my mind:
> a) Don't refer to the directory vnode for sillyrenames - just save the
>    file handle and necessary information as eg v2/v3. This would require
>    to implement the "remove" RPC call especially for this purpose.
> b) Rethink the locking. Add a reference to the directory vnode if a
>    "sillyrename" occurs, and hack some more code to obey this at vflush()
>    time. Forcing all dirs where sillyrenames occured to occupy vnodes
>    is nasty...
> c) In nfs_inactive, if it is a directory, check whether there are
>    sillyrenames pending on it and process them first. This needs more
>    considerations because the sillyrenamed vnode might be still in use...
>
> Atm, only (a) looks viable for me.

(a) looks like the best.

Thanks for looking into this.

Take care,

Bill