Re: tstile syndrome

[David Holland <dholland-tech%netbsd.org@localhost>]

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.

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

 > 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.

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