Re: More duplicate code, vnode locking question

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Thu Apr 23 2009 at 00:56:03 +0300, Elad Efrat wrote:
> On Thu, Apr 23, 2009 at 12:42 AM, Antti Kantee <pooka%cs.hut.fi@localhost> 
> wrote:
> 
> >>   - How does locking devvp violate the locking order of vnodes? (note
> >>     that I'm not suggesting it doesn't)
> >
> > I wrote that in the previous email.  You always lock from root down.
> > If you don't know the relationship of two vnodes, you cannot lock
> > them both at the same time.  In this case you are already holding the
> > mountpoint lock.
> >
> > Like I also wrote, the mount path locking is special because of recursive
> > locks (which combined with namei already is a deadlock waiting to
> > happen!).  No point in fussing around if you can't fix anything.
> >
> >>   - How do we weigh what is a more severe bug? :)
> >
> > i decide ;)
> 
> :)

;)

> For now I'll just focus on my original goal then, and it looks like
> requiring that devvp is locked for genfs_can_mount() is okay, so I'll
> just do that.

Sounds good, although I still don't support putting it into genfs.
Pulling it out later may create more work and mess than just defining
a new module (yes, I do have quite a bit of recent experience on the
subject).  Maybe we can call it vfscomp_can_mount() for vfs component,
or even compvfs_can_mount.  ... Ok, it's not *that* important currently,
call it whatever you want.