Re: [ANN] unionfs patchset-16 release, it is ready for the merge

From: Kris Kennaway <kris_at_obsecurity.org>
Date: Mon, 4 Sep 2006 14:47:17 -0400
On Sun, Sep 03, 2006 at 01:20:33PM -0400, Kris Kennaway wrote:
> On Sun, Sep 03, 2006 at 01:01:29PM -0400, Kris Kennaway wrote:
> > On Fri, Jul 14, 2006 at 03:56:54PM +0900, Daichi GOTO wrote:
> > > Daichi GOTO wrote:
> > > > Patchset-16:
> > > >    For 7-current
> > > >      http://people.freebsd.org/~daichi/unionfs/unionfs-p16.diff
> > > > 
> > > >    For 6.x
> > > >      http://people.freebsd.org/~daichi/unionfs/unionfs6-p16.diff
> > > 
> > > I'm sorry, how silly of me. I updated miss edited things.
> > > I updated correct things now. Please check it :)
> > 
> > Dear Goto-san,
> > 
> > The panic I was previously seeing (with chrooting into the unionfs)
> > appears to be fixed, but after a bit of load I got the following
> > locking assertion on a unionfs (default mount options) stacked over a
> > nullfs mount of a local ufs filesystem:
> 
> I got the same panic from a mount_unionfs -b mount with no nullfs
> involved.

Another panic from mount_unionfs -b when just running 'vi' on a file.
By the way, I recommend you run with DEBUG_LOCKS and DEBUG_VFS_LOCKS
if you're not already doing so, because it looks like there are still
a number of locking problems.

vfs_badlock(cc6c63f0,ea3c7a88,c07c5940,cc6c63f0,c49b2a20,225) at vfs_badlock+0x76
assert_vop_elocked(cc6c63f0,c0782231,c05af3de,c4eb3780,cc6c63f0,...) at assert_vop_elocked+0x63
VOP_CLOSE_APV(c07b2680,ea3c7ac8,c07c5780,cc6c63f0,4005,...) at VOP_CLOSE_APV+0x87
unionfs_close(ea3c7b2c,c0782231,4005,4005,cdb20000,...) at unionfs_close+0x5c
VOP_CLOSE_APV(c0797ca0,ea3c7b2c,c49b2a20,11a,c4d0f5a8,...) at VOP_CLOSE_APV+0x94
vn_close(cdb20000,4005,c51fa000,c49b2a20,c07c5040,...) at vn_close+0x85
vn_closefile(c4c80318,c49b2a20,c07570d9,871,cdb20000,...) at vn_closefile+0x8b
fdrop_locked(c4c80318,c49b2a20,c07570d9,7a2,c075adae,314,1,c8db9aa8,c4ddc704,c4ddc69c,ea3c7c58,0,ea3c7d04,d109f62c,3e9,c07570d9,ea3c7c50,c053ba1b,d109f62c,1,c0759a43,16a,0) at fdrop_locked+0xb9
closef(c4c80318,c49b2a20,c07570d9,3e9,c49b2a20,...) at closef+0x1f7
kern_close(c49b2a20,3,4,ea3c7d38,1,...) at kern_close+0x188
syscall(3b,3b,3b,0,2820c4e0,...) at syscall+0x152
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (6, FreeBSD ELF32, close), eip = 0x281e5ddf, esp = 0xbfbfe45c, ebp = 0xbfbfe468 ---
VOP_CLOSE: 0xcc6c63f0 is not exclusive locked but should be

db> show lockedvnods
Locked vnodes

0xcf1a0930: tag ufs, type VREG
    usecount 1, writecount 0, refcount 3 mountedhere 0
    flags ()
    v_object 0xc7ac3e10 ref 0 pages 1
     lock type ufs: EXCL (count 1) by thread 0xc49b2a20 (pid 85878)#0 0xc0537384 at lockmgr+0x541
#1 0xc06950ce at ffs_lock+0x59
#2 0xc0730898 at VOP_LOCK_APV+0x76
#3 0xc05045db at unionfs_lock+0xda
#4 0xc0730898 at VOP_LOCK_APV+0x76
#5 0xc05c7b22 at vn_lock+0x67
#6 0xc05c81ad at vn_close+0x51
#7 0xc05c94cb at vn_closefile+0x8b
#8 0xc051d37d at fdrop_locked+0xb9
#9 0xc051d67d at closef+0x1f7
#10 0xc051dfff at kern_close+0x188
#11 0xc07161b3 at syscall+0x152
#12 0xc06fefef at Xint0x80_syscall+0x1f

        ino 353856, on dev da0s1e

0xcdb20000: tag unionfs, type VREG
    usecount 1, writecount 0, refcount 1 mountedhere 0
    flags ()
    v_object 0xc76f0708 ref 0 pages 1
     lock type ufs: EXCL (count 1) by thread 0xc49b2a20 (pid 85878)#0 0xc0537384 at lockmgr+0x541
#1 0xc06950ce at ffs_lock+0x59
#2 0xc0730898 at VOP_LOCK_APV+0x76
#3 0xc05045db at unionfs_lock+0xda
#4 0xc0730898 at VOP_LOCK_APV+0x76
#5 0xc05c7b22 at vn_lock+0x67
#6 0xc05c81ad at vn_close+0x51
#7 0xc05c94cb at vn_closefile+0x8b
#8 0xc051d37d at fdrop_locked+0xb9
#9 0xc051d67d at closef+0x1f7
#10 0xc051dfff at kern_close+0x188
#11 0xc07161b3 at syscall+0x152
#12 0xc06fefef at Xint0x80_syscall+0x1f

unionfs_vp=0xcdb20000, uppervp=0xcf1a0930, lowervp=0xcc6c63f0
unionfs opencnt: uppervp=0, lowervp=1
unionfs: upper
0xcf1a0930: tag ufs, type VREG
    usecount 1, writecount 0, refcount 3 mountedhere 0
    flags ()
    v_object 0xc7ac3e10 ref 0 pages 1
     lock type ufs: EXCL (count 1) by thread 0xc49b2a20 (pid 85878)#0 0xc0537384 at lockmgr+0x541
#1 0xc06950ce at ffs_lock+0x59
#2 0xc0730898 at VOP_LOCK_APV+0x76
#3 0xc05045db at unionfs_lock+0xda
#4 0xc0730898 at VOP_LOCK_APV+0x76
#5 0xc05c7b22 at vn_lock+0x67
#6 0xc05c81ad at vn_close+0x51
#7 0xc05c94cb at vn_closefile+0x8b
#8 0xc051d37d at fdrop_locked+0xb9
#9 0xc051d67d at closef+0x1f7
#10 0xc051dfff at kern_close+0x188
#11 0xc07161b3 at syscall+0x152
#12 0xc06fefef at Xint0x80_syscall+0x1f

        ino 353856, on dev da0s1e
unionfs: lower
0xcc6c63f0: tag ufs, type VREG
    usecount 1, writecount 0, refcount 3 mountedhere 0
    flags ()
    v_object 0xc76f0708 ref 0 pages 1
    #0 0xc0537384 at lockmgr+0x541
#1 0xc06950ce at ffs_lock+0x59
#2 0xc0730898 at VOP_LOCK_APV+0x76
#3 0xc05c7b22 at vn_lock+0x67
#4 0xc05bb8d2 at vget+0x77
#5 0xc05ac279 at cache_lookup+0xe7
#6 0xc05acc5e at vfs_cache_lookup+0xad
#7 0xc072e81c at VOP_LOOKUP_APV+0x9c
#8 0xc050226a at unionfs_lookup+0x3b2
#9 0xc072e81c at VOP_LOOKUP_APV+0x9c
#10 0xc05b0f06 at lookup+0x319
#11 0xc05b1c3a at namei+0x358
#12 0xc05c1b9f at kern_access+0x72
#13 0xc05c1c5e at access+0x29
#14 0xc07161b3 at syscall+0x152
#15 0xc06fefef at Xint0x80_syscall+0x1f

        ino 259241, on dev da0s1e
db> ps
  pid  ppid  pgrp   uid   state   wmesg     wchan    cmd
85878   852 85878     0  R+      CPU 0               vi
...
Received on Mon Sep 04 2006 - 16:47:18 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:59 UTC