[PATCH] Make udf(4) MPSAFE and use shared lookups

John Baldwin jhb at freebsd.org
Fri Nov 21 11:59:15 PST 2008


On Thursday 20 November 2008 06:32:25 pm Paul B. Mahol wrote:
> On 11/20/08, John Baldwin <jhb at freebsd.org> wrote:
> > So this patch is fairly minimal since udf(4) is currently read-only.  The
> > changes include:
> >
> > * Set VV_ROOT in udf_vget() if we ever return a vnode instead of doing it
> > only
> >   in udf_root().  This matches the behavior of other operating systems and
> >   correctly tags the root vnode with VV_ROOT in the unlikely case that we
> >   create the vnode during a call to ufs_vget() that does not come from
> >   ufs_root().
> > * If the hash lookup in ufs_vget() fails, ensure an exclusive vnode lock 
is
> >   used while creating the new vnode (same as UFS).
> > * Allow lock recursion (XXX: not really sure this is needed actually).
> > * Allow shared vnode locks on non-fifos.
> > * Honor the requested locking flags (shared vs exclusive) instead of 
always
> >   using exclusive vnode locks during a lookup operation.
> > * Handle "." lookups the same way other filesystems do by just bumping the
> >   reference on 'dvp' rather than calling udf_vget().
> >
> > http://www.FreeBSD.org/~jhb/patches/udf_mpsafe.patch
> >
> > I have only verified that this compiles and would appreciate it if some
> > folks
> > could test this, preferable with INVARIANTS and DEBUG_VFS_LOCKS enabled.
> 
> I lightly tested it with md(4) on 47M size iso created with k3b
> (it contains two files)
> 
> I only got this lor related to udf:
> 
> lock order reversal:
>  1st 0xc4449270 udf (udf) @ /usr/src/sys/kern/vfs_lookup.c:442
>  2nd 0xd7d10850 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443
>  3rd 0xc4399488 udf (udf) @
> /usr/src/sys/modules/udf/../../fs/udf/udf_vfsops.c:625

I think you would get this same LOR w/o the patch.  I think cd9660 might have 
the same bug.  The issue is holding a buffer from bread() (i.e. not calling 
brelse() yet) while calling udf_vget() in udf_lookup().

-- 
John Baldwin


More information about the freebsd-current mailing list