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

Paul B. Mahol onemda at gmail.com
Thu Nov 20 15:32:26 PST 2008

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) @
KDB: stack backtrace:
db_trace_self_wrapper(c069d7d4,c3b6181c,c04e745f,4,c0698f19,...) at
kdb_backtrace(4,c0698f19,c3cb7538,c3cb9ca0,c3b61878,...) at kdb_backtrace+0x29
_witness_debugger(c06a04a1,c4399488,c43bc47c,c3cb9ca0,c43bc3f6,...) at
witness_checkorder(c4399488,9,c43bc3f6,271,0,...) at witness_checkorder+0x811
__lockmgr_args(c4399488,80000,0,0,0,...) at __lockmgr_args+0x762
udf_vget(c43a2500,4,200000,c3b619bc,0,...) at udf_vget+0x131
udf_lookup(c3b619fc,c4449218,c3b61bb4,c4449218,c3b61a1c,...) at udf_lookup+0x277
vfs_cache_lookup(c3b61a7c,c3b61a7c,0,200000,c4449218,...) at
VOP_LOOKUP_APV(c43bda80,c3b61a7c,c06a61d2,1ba,c3b61ba0,...) at
lookup(c3b61b88,c06a61d2,dc,bc,c4184c2c,...) at lookup+0x507
namei(c3b61b88,c06a5efc,143,0,c4446240,...) at namei+0x45b
kern_statat(c4446240,200,ffffff9c,28304c40,0,...) at kern_statat+0x66
kern_lstat(c4446240,28304c40,0,c3b61c1c,0,...) at kern_lstat+0x36
lstat(c4446240,c3b61cf8,8,c06a1154,c06cf170,...) at lstat+0x2b
syscall(c3b61d38) at syscall+0x261
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (190, FreeBSD ELF32, lstat), eip = 0x281f132b, esp =
0xbfbfe5ec, ebp = 0xbfbfe6b8 ---

lor also happen sometimes when umounting fs.

More information about the freebsd-current mailing list