doing vfs_hash_get when vnode locked

[Rick Macklem]

On Tue, Aug 05, 2008 at 04:58:30PM -0400, Rick Macklem wrote:
[stuff snipped] 
>> The way I just coded it is:
>> - the function that does the vfs_hash_get() without LK_EXCLUSIVE just
>>   fails if MNTK_UNMOUNTF is set.
>> - my nfs_close just returns when MNTK_UNMOUNTF is set.
>> - my nfs_unmount() doesn't set FORCECLOSE on the vflush() but instead
>>   sleeps and retries a bunch of times if vflush() fails for MNT_FORCE.
>> - my nfs_unmount() and other code (mostly based on the vanilla FreeBSD
>>   client makes requests all fail with EINTR when MNTK_UNMOUNTF is set).
> You still has the race where the MNTK_UNMOUNTF is set after you check
> returned false, isn't it ?

I don't think it will be an issue, but I haven't tested the forced
unmount without FORCECLOSE yet.

> BTW, is your fs marked as mpsafe ?

Yep. Except for the low level code doing the RPCs, the client side is
basically a clone of the regular nfsclient.

> Yes, ATM it should be safe, since only vflush() does reclamation for the
> vnodes with usecount > 0. On the other hand, I believe our VFS never
> makes a guarantee that this is the only location of the call.

Well, at this point, vflush() only seems to be called inside the file
systems for a mount point of that file system type. If someone adds a
vflush() with FORCECLOSE outside of my code that acts on a mountpoint
for my nfs client, it could break horribly. That's life in this game;-)

I'm thinking about how to avoid this, but it ain't gonna be trivial and
it could be ugly. (The short version is that, for nfsv4, the nfs part of
the vnode must keep the directory fh and component name of the file in it,
so that Opens can be done. That's ugly enough, given renames and multiple
hard links to a file. If I can't get at that nfs vnode, I'll have to keep
a copy of the directory fh and component name in the Open data structure,
which wouldn't be too bad until a rename occurs.) I might try and do this
in the next month or so...

rick