knotes and force unmount

[Jeff Roberson]

On Wed, 4 Mar 2009, Matthew Fleming wrote:

> At close() time knote_fdclose() will take care of any outstanding knotes
> for the file by looping over the list, calling kn_fop->f_detach and then
> knote_drop().  For a umount -f, there may still be open files; these
> will be handled in vgonel() by a call to VOP_CLOSE().  knotes are
> untouched in this case.
>
> If the filesystem is from a loadable module, then the knotes need to be
> cleaned up before the module is unloaded to prevent a callout into code
> that no longer exists, when the file is later closed.  So it seems like
> there is code missing from vgonel() that should be doing this for the
> case where it calls VOP_CLOSE().  I realize this isn't a problem for ufs
> (never unloaded because it's used for /) and NFS (no events), but for
> any other filesystem this seems like a hole in the force unmount story.
>
> Is this interpretation correct?  It would always be possible to add code
> to a filesystem's vop_close routine or its unmount routine, but
> architecturally this seems like something that should be handled at
> vgonel->VOP_CLOSE time, because it's a problem for any loadable
> filesystem with events.

Hi Matthew,

This is actually a problem for any VOP with "U U U" in the vnode_if.src 
specification.  Forced unmounts are delayed by vnode locks held but 
several vops don't hold vnode locks and instead rely on other locking.

We have the same problem with loadable syscalls.  How can you tell when 
the code is no longer in use?  The right answer would probably be to wait 
for every thread that is currently in a syscall to leave once before 
unloading completely.  This would solve syscalls and your loadable module 
case.  Although it would be complicated by nfs which doesn't use syscalls 
but does issue VOPs.

I believe a general solution for syscalls/loadable modules would solve 
this case.  Don't you think?  I thought Isilon already did something for 
this?  Or is this something you're only discovering since you've merged? 
If you're interested in working on this I can help you implement a general 
solution.

Thanks,
Jeff

>
> Thanks,
> matthew
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>