hi, > On Thu, Jun 25, 2009 at 12:47:38AM +0000, YAMAMOTO Takashi wrote: >> > On Wed, Jun 24, 2009 at 02:21:44PM +0000, YAMAMOTO Takashi wrote: >> >> Module Name: src >> >> Committed By: yamt >> >> Date: Wed Jun 24 14:21:44 UTC 2009 >> >> >> >> Modified Files: >> >> src/sys/kern [yamt-nfs-mp]: vfs_syscalls.c >> >> src/sys/nfs [yamt-nfs-mp]: nfs_vfsops.c nfs_vnops.c >> >> >> >> Log Message: >> >> lock vnode when calling VOP_GETATTR because there's no reasonable way for >> >> an implementation of VOP_GETATTR to prevent the vnode from being revoked. >> > >> > I've not looked at the specific code, but surely a reference count is >> > enough? >> > Requiring callers to lock vnodes doesn't seem right to me - since it >> > is only likely to cause locking violations in layered fs. >> > >> > The fact that the caller has a reference to the vnode at all should >> > really be enough, surely?? >> >> do you mean vref? >> it doesn't prevent revoke(2). >> thus a filesystem can't access v_data safely. > > How does Solaris do this? My understanding is you _don't_ have to lock > nodes any where near as often as we do (or did last I looked, which was > admittedly a while ago). > > I think we should steal some other OSs vnode interface, at least as far as > locking and reclaim logic. Since we are turning into SolarisBSD (a good > thing!), it's a likely choice. > > Other OSs have faced this issue and fixed it. Let's learn from them. :-) > > Take care, > > Bill
iirc, - solaris doesn't have revoke. (i don't know what it does for forced unmount.) - freebsd removed the support of revoking non-device files. - dragonflybsd has some change in this area. anyway, fixing revoke is not in the scope of this branch. :-) YAMAMOTO Takashi