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

On 11/21/08, John Baldwin <jhb_at_freebsd.org> wrote:
> 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) _at_ /usr/src/sys/kern/vfs_lookup.c:442
>>  2nd 0xd7d10850 bufwait (bufwait) _at_ /usr/src/sys/kern/vfs_bio.c:2443
>>  3rd 0xc4399488 udf (udf) _at_
>> /usr/src/sys/modules/udf/../../fs/udf/udf_vfsops.c:625
>
> I've updated the patch at the same URL above to fix this LOR.
>
> --
> John Baldwin
>

Some bad news, using new patch (did not tested agains old one) I was able
to reliable panic system with 3.4GB iso, trying to play music files via cplay.

here is backtrack, from textdump:

db:1:lockinfo> show locks
db:1:locks>  show alllocks
Process 977 (python) thread 0xc43b4d80 (100087)
db:1:alllocks>  show lockedvnods
Locked vnodes
db:0:kdb.enter.panic>  show pcpu
cpuid        = 1
curthread    = 0xc43b4d80: pid 977 "initial thread"
curpcb       = 0xc3b67d90
fpcurthread  = none
idlethread   = 0xc3d2ad80: pid 10 "idle: cpu1"
APIC ID      = 1
currentldt   = 0x50
spin locks held:
db:0:kdb.enter.panic>  bt
Tracing pid 977 tid 100087 td 0xc43b4d80
kdb_enter(c069b0df,c069b0df,c06a5d32,c3b67968,1,...) at kdb_enter+0x3a
panic(c06a5d32,10800,10000,c0686786,c3b679d0,...) at panic+0x131
getblk(c4e0e10c,424,0,10800,0,...) at getblk+0x2d
breadn(c4e0e10c,424,0,10800,0,...) at breadn+0x44
bread(c4e0e10c,424,0,10800,0,...) at bread+0x4c
udf_readatoffset(1a18,0,c50568d8,c50568dc,0,...) at udf_readatoffset+0xbb
udf_getfid(c4694680,ffffffff,c3b67cf8,c06a8594,c3b67c24,...) at udf_getfid+0x1ca
udf_readdir(c3b67c24,0,c4555648,0,c3b67c5c,...) at udf_readdir+0xdc
VOP_READDIR_APV(c4faf280,c3b67c24,c06a8594,ff3,1a18,...) at VOP_READDIR_APV+0xa0
kern_getdirentries(c43b4d80,46,2844c000,1000,c3b67c78,...) at
kern_getdirentries+0x1bd
getdirentries(c43b4d80,c3b67cf8,10,c06a1b96,c06cfbe0,...) at getdirentries+0x31
syscall(c3b67d38) at syscall+0x261
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (196, FreeBSD ELF32, getdirentries), eip = 0x28251e4b, esp
= 0xbfbfe27c, ebp = 0xbfbfe2a8 ---


and panic message:

uiomove returned -1
panic: getblk: size(67584) > MAXBSIZE(65536)

cpuid = 1
KDB: enter: panic
exclusive lockmgr udf (udf) r = 0 (0xc45556a0) locked _at_
/usr/src/sys/kern/vfs_syscalls.c:4083
exclusive lockmgr udf (udf) r = 0 (0xc45556a0) locked _at_
/usr/src/sys/kern/vfs_syscalls.c:4083

0xc4555648: tag udf, type VDIR
    usecount 1, writecount 0, refcount 1 mountedhere 0
    flags ()
    v_object 0xc479ac98 ref 0 pages 0
     lock type udf: EXCL by thread 0xc43b4d80 (pid 977)

-- 
Paul