[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: [yamt-nfs-mp] src/sys
> 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,
- solaris doesn't have revoke. (i don't know what it does for
- 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. :-)
Main Index |
Thread Index |