Re: [ANN] unionfs patchset-17 release, lock mechanism changed for robust working

From: Kris Kennaway <kris_at_obsecurity.org>
Date: Sat, 2 Dec 2006 17:36:21 -0500
On Sat, Dec 02, 2006 at 05:24:23PM -0500, Kris Kennaway wrote:
> On Fri, Dec 01, 2006 at 10:38:34PM +0900, Daichi GOTO wrote:
> > Hi Guys!
> > 
> > It is my pleasure and honor to announce the availability of
> > the unionfs patchset-17. p17 have some significant improvements
> > around the lock mechanism for robust and stable working.
> 
> I got the following locking assertion as soon as I tried to start a
> package build in the unionfs -b mountpoint.

Even simpler test:

mount_unionfs /usr/src /c/test/src
cd /c/test/src
make buildworld -j4

panics immediately with:

db_trace_self_wrapper(c5685a80,ecd01ab4,c073871a,ecd01ac4,c57af560,...) at db_trace_self_wrapper+0x37
vfs_badlock(c57af560,ecd01ac4,c07d4d20,c57af560,c5685a80,c07ea370) at vfs_badlock+0x76
assert_vop_elocked(c57af560,c0760340,ecd01b78,c4fb8a00,ecd01b78,...) at assert_vop_elocked+0x63
unionfs_get_node_status(c4fb8a00,c5685a80,ecd01b0c,c054a2cc,c5683d88,...) at unionfs_get_node_status+0x29
unionfs_ioctl(ecd01b78,c078ed87,ecd01c0c,c57af560,0,...) at unionfs_ioctl+0x2e
VOP_IOCTL_APV(c07a4e00,ecd01b78,c0771b2f,2e7,0,...) at VOP_IOCTL_APV+0x94
vn_ioctl(c53aaa20,402c7413,c5786700,c55a9000,c5685a80,...) at vn_ioctl+0x135
kern_ioctl(c5685a80,3,402c7413,c5786700,c5786700,...) at kern_ioctl+0x8a
ioctl(c5685a80,ecd01d04,c,ecd01d38,3,...) at ioctl+0xac
syscall(3b,3b,3b,0,8220160,...) at syscall+0x152
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2817fb6f, esp = 0xbfbfdbdc, ebp = 0xbfbfdbf8 ---
unionfs_get_node_status: 0xc57af560 is not exclusive locked but should be

db> show lockedvnods
Locked vnodes

0xc57a0000: tag ufs, type VREG
    usecount 0, writecount 0, refcount 3 mountedhere 0
    flags ()
    v_object 0xc575d3c0 ref 0 pages 1
     lock type ufs: EXCL (count 1) by thread 0xc5399540 (pid 1512)#0 0xc0545c13 at _lockmgr+0x538
#1 0xc06a766f at ffs_lock+0x6a
#2 0xc0738675 at _VOP_LOCK_APV+0x69
#3 0xc05d7f4a at _vn_lock+0x73
#4 0xc05cb994 at vget+0x8b
#5 0xc05bfd42 at vfs_hash_get+0x105
#6 0xc06a3003 at ffs_vget+0x49
#7 0xc06add11 at ufs_lookup+0x967
#8 0xc0739a97 at VOP_CACHEDLOOKUP_APV+0x94
#9 0xc05bc44d at vfs_cache_lookup+0xec
#10 0xc0739bd1 at VOP_LOOKUP_APV+0x9c
#11 0xc05c0971 at lookup+0x36c
#12 0xc05c1703 at namei+0x358
#13 0xc05d17ed at kern_unlink+0x60
#14 0xc05d19f9 at unlink+0x22
#15 0xc072156b at syscall+0x152
#16 0xc07093af at Xint0x80_syscall+0x1f

        ino 10729, on dev da0s1a
db>

Please don't take this the wrong way, but I wonder if your internal
tests can be improved so we don't have to go through this kind of
extended debugging cycle.

Kris


Received on Sat Dec 02 2006 - 21:36:47 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:03 UTC