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>