knotes and force unmount
jroberson at jroberson.net
Wed Mar 4 21:44:45 PST 2009
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.
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
> freebsd-arch at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
More information about the freebsd-arch