Re: Replace lockmgr for vnodes

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

On Sat, Mar 01, 2008 at 02:15:25PM +0200, Antti Kantee wrote:
 > > Yes and no. What you say is perfectly true, and the mess that
 > > currently exists should not be allowed to contine.
 > > 
 > > That said, by "get it wrong" I mean things like ufs_rename(), or
 > > worse, msdosfs_rename(), rename being particularly difficult to get
 > > right - things where the per-fs code gets locks in the wrong order, or
 > > gets the wrong locks, or doesn't bother getting them at all, or drops
 > > things on the floor when it's halfway done, or whatever other creative
 > > lossage someone manages to invent.
 > 
 > I don't buy that either.  You need to manipulate locks inside the fs
 > for rename anyway.  That's the hard part.  Complying with the locking
 > protocol is trivial compared to that.

Well, yes. But that's the point. If it were feasible to have vfs (or
genfs) do all the locking for rename before getting into the
fs-dependent code, it would mean that in most cases the fs wouldn't
have the opportunity to get it wrong.

 > > If the locking is provided in fs-independent code, then it only needs
 > > to be debugged once.
 > 
 > And I don't buy that either.  I think there are more locking problems
 > outside of file systems than in them (because of namei).

I doubt that. While namei is certainly a mess (and is the proximate
cause of substantial mess in every fs function that receives a
componentname) its locking is basically very simple. Whereas I think
it's pretty safe to assume at this point that almost every rename
implementation is wrong in some fashion.

 > That said, if all approaches suck, why not let the file system decide.
 > It should know best what kind of locking it needs.  Well, that's my
 > opinion for the current mess.  If you're going to propose something
 > wildly different, I'm all ears.

In practice I think for most operations there's a natural place to
take the locks, based on what's being done, and a natural place to
call from fs-independent into fs-dependent code, based on when
fs-specific logic is first needed. For some operations the locking
comes first; for some operations the call more naturally comes
first. My contention is that in the former case it's better to have
the locking outside the fs so it only needs to be fixed once, and in
the latter case it would be good to have a reasonable way to make the
locking logic fs-independent anyway, for the same reason.

I am not convinced that there are really fses where the standard
sequence of locking operations isn't correct, but if there are, then
the genfs approach would still allow them to do their own thing if
they really needed to. The catch is that as I've said before I don't
think it's a good idea to go adding tons more stuff to genfs without
some kind of management mechanism; otherwise the complexity will get
out of hand.

In any event though I think vops should be symmetric with respect to
locking and reference counting. (Except for the obvious exception of
lookup returning a reference to a new vnode.)

Migrating to such a world will not be entirely trivial, but I think we
should do it at some point.

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