panic under FUSE: lockmgr: locking against myself

[Ulrich Spoerlein]

Hi,

I need to transfer a Windows installation from a broken drive to a new
one. I already salvaged the old disk using recoverdisk(1) and now want
to write to the new disk using fusefs-ntfs aka. ntfs-3g.

I can read from NTFS via FUSE just fine, writing is also no problem if
I'm using 'cp -pr', but since I want to copy selectively I'm using
'find | cpio -dump', this panics the box after a few seconds.

I'm using a recent 8.0-CURRENT and the fuse ports are up to date. Here's
the panic:

panic: lockmgr: locking against myself
KDB: stack backtrace:
db_trace_self_wrapper(c071561a,cf349ae8,c0537d2a,c07138c3,c077e480,...) at db_trace_self_wrapper+0x26
kdb_backtrace(c07138c3,c077e480,c0711f62,cf349af4,cf349af4,...) at kdb_backtrace+0x29
panic(c0711f62,c073f0a0,c266b3b8,c0767fe0,c266b330,...) at panic+0xaa
_lockmgr(c266b168,3002,c266b198,c255f840,c071a143,...) at _lockmgr+0x432
vop_stdlock(cf349b84,c05a41f1,1002,c266b110,cf349ba8,...) at vop_stdlock+0x40
VOP_LOCK1_APV(c2380ba0,cf349b84,cf349ba8,c05bf022,c2380ba0,...) at VOP_LOCK1_APV+0x46
_vn_lock(c266b110,1002,c255f840,c071a143,a6c,...) at _vn_lock+0x16f
setfown(0,4,cf349c70,c2634550,c255f840,...) at setfown+0x9c
fchown(c255f840,cf349cfc,c,86,55349d,...) at fchown+0x134
syscall(cf349d38) at syscall+0x345
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (123, FreeBSD ELF32, fchown), eip = 0x280defa7, esp = 0xbfbfeb9c, ebp = 0xbfbfeca8 ---
KDB: enter: panic
[thread pid 984 tid 100087 ]
Stopped at      kdb_enter+0x32: leave
db> show lockedvnods
Locked vnodes

0xc266b110: tag fuse, type VREG
    usecount 1, writecount 1, refcount 1 mountedhere 0
    flags ()
    v_object 0xc266e364 ref 0 pages 0
     lock type fuse: EXCL (count 1) by thread 0xc255f840 (pid 984)
nodeid: 11, parent_nid: 5, fh_counter: 1, nlookup: 1, flags: 0

PID 984 is cpio(1).

This must be a locking bug in our FUSE layer, as ntfs-3g is a user
process and shouldn't be able to panic the system.

Is cp(1) -p not using fchown? Or why is it not affected? Shall I try
tar(1) instead?

Cheers,
Ulrich Spoerlein
-- 
It is better to remain silent and be thought a fool,
than to speak, and remove all doubt.