Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Nov 2008 00:32:25 +0100
From:      "Paul B. Mahol" <onemda@gmail.com>
To:        "John Baldwin" <jhb@freebsd.org>
Cc:        scottl@freebsd.org, current@freebsd.org
Subject:   Re: [PATCH] Make udf(4) MPSAFE and use shared lookups
Message-ID:  <3a142e750811201532u6e697488w2747242e0a8614a9@mail.gmail.com>
In-Reply-To: <200811201627.58289.jhb@freebsd.org>
References:  <200811201627.58289.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 11/20/08, John Baldwin <jhb@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
KDB: stack backtrace:
db_trace_self_wrapper(c069d7d4,c3b6181c,c04e745f,4,c0698f19,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(4,c0698f19,c3cb7538,c3cb9ca0,c3b61878,...) at kdb_backtrace+0x29
_witness_debugger(c06a04a1,c4399488,c43bc47c,c3cb9ca0,c43bc3f6,...) at
_witness_debugger+0x1e
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
VOP_CACHEDLOOKUP_APV(c43bda80,c3b619fc,c3b61bb4,c3b61ba0,c06f9a20,...)
at VOP_CACHEDLOOKUP_APV+0xa0
vfs_cache_lookup(c3b61a7c,c3b61a7c,0,200000,c4449218,...) at
vfs_cache_lookup+0xc3
VOP_LOOKUP_APV(c43bda80,c3b61a7c,c06a61d2,1ba,c3b61ba0,...) at
VOP_LOOKUP_APV+0xaa
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3a142e750811201532u6e697488w2747242e0a8614a9>