Re: tstile syndrome

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> On Thu, Sep 24, 2009 at 06:05:47AM +0000, YAMAMOTO Takashi wrote:
>  > > But I have two things to say: (1) locking a per-vnode lock directly is
>  > > no different from calling vn_lock() -> VOP_LOCK() to lock a per-vnode
>  > > lock, and this appears to be what the rename logic does; and (2) while
>  > > it isn't cut-and-pasted all the lock-handling code for rename is
>  > > exactly an example of what ought to be fs-independent.
>  > 
>  > parent-to-children order vnode locking is one of things which
>  > complicate our rename.  inode-number order locking can simplify it
>  > because it's easier to lock multiple inodes in that way.
> 
> Only if you're willing to make heavy use of relookup() and run the
> risk of subtle concurrency issues. If the number order is such that
> you have to unlock the parent before locking the child, then you
> aren't atomic any more, and relookup is at best a band-aid for that.

what kind of atomicity are you talking about here?

sure, we need to ensure that the files are still in the expected state
after relock.

> 
> To the best of my knowledge there's only one way to do rename
> correctly. (Two if you count doing strict two-phase locking.) 

can you please explain a bit more about "correctly"?

> 
>  > besides that, the assumption that all filesystems need the same
>  > cut-and-pasted locking is wrong.  there are filesystems which have
>  > fundamentally different locking requirements.  nfs is an obvious example.
> 
> Yes and no. Most of the locking requirements and locking structure
> arises from the atomicity semantics of the system calls. That's
> fs-independent. Even with nfs's creative consistency model you still
> need e.g. the logic that makes O_EXCL (locally) atomic.
> 
> Anyhow, it's not cut-and-paste of locking as such that concerns me so
> much as cut-and-paste of things like the O_EXCL code, which is
> security-critical. Maybe it can be done in genfs; however, that would
> probably just end up trading VOP_LOCK() for gop_lock(), which is not
> an improvement.

O_EXCL isn't a good example because nfsv3 can handle it remotely.

YAMAMOTO Takashi

> 
> -- 
> David A. Holland
> dholland%netbsd.org@localhost