Arla on FreeBSD

[Tomas Olsson]

Kostik Belousov <kostikbel at gmail.com> writes:
> On Thu, Feb 15, 2007 at 02:07:19PM +0100, Tomas Olsson wrote:
> > Ok, vn_open() must be passed curthread so we can't use arlad's thread when
> > in our VOP.  And we cannot use an absolute path to the cache. So vn_open()
> > can't be used?  
> vn_open() does not need curthread in strong sence, but td is the thread
> that all locks and sleeps will be performed for.
>
Except in places like vput() and vrele()?
        struct thread *td = curthread;  /* XXX */

> I think that your current strategy would work, but it needs to be checked.
>
Nice.  Possibly there are still a few places where I mix contexts too much
as well. And I've probably missed a few mandatory support routines along
the lines of vn_start_write().

> > So where does this leave us, is plain lookup() (or VOP_LOOKUP) and
> > VOP_CREATE on the cache a possible way to go?  Seems to work on OpenBSD.
> vn_open() is the right way. Otherwise, you would in fact reimplement the
> code from it.
>
I know, I just don't see how to get around it.

> Also, you could look at file handle API, that would save you of path lookups
> after the vnode is looked up first time (look around for vfs_vptofh and
> vfs_fhtovp ops). This API is used by NFS server, so it shall work :).
>
That's an idea. We used that before in another context, but then we ran
into trouble with too many OSes so we dropped it.  Depends on how much code
one can share.

> > Well, it's marked "doesn't need giant"; we use our own global lock. I don't
> > trust it 100%, but it seems to work so far.  I haven't tried it on any MP
> > FreeBSD boxes though.
> 
> Again, this could lead to lock order reversals with vnode lock. For
> instance, when lookup() traverses tree, it has the parent directory
> locked and calls fs-provided VOP_LOOKUP(). This method shall return the
> leaf vnode locked. Since, according to you claim, some alra-specific
> global lock is taken between these two vnode locks, it could LOR between
> vnode locks and alra lock
>
I'm not sure if that's currently a problem for us, but I'll take a
look.  I'm sure there are other cases.

thanks
        /t