From owner-freebsd-stable@FreeBSD.ORG Sun Mar 5 23:51:11 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6A8616A420 for ; Sun, 5 Mar 2006 23:51:11 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63F3043D46 for ; Sun, 5 Mar 2006 23:51:11 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from [10.0.0.1] (67-40-203-22.tukw.qwest.net [67.40.203.22]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.1/8.13.1) with ESMTP id k25Np7iG058037; Sun, 5 Mar 2006 18:51:08 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sun, 5 Mar 2006 15:49:20 -0800 (PST) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Kostik Belousov In-Reply-To: <20060304091522.GD37572@deviant.kiev.zoral.com.ua> Message-ID: <20060305154820.J557@10.0.0.1> References: <20060303153833.Q557@10.0.0.1> <20060304091522.GD37572@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.52 on 216.240.101.25 Cc: stable@freebsd.org Subject: Re: VFS MFC testers wanted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2006 23:51:11 -0000 On Sat, 4 Mar 2006, Kostik Belousov wrote: > On Fri, Mar 03, 2006 at 03:41:55PM -0800, Jeff Roberson wrote: >> I plan to MFC all of this lovely stuff for 6.1: >> >> http://www.chesapeake.net/~jroberson/vfsmfc.diff >> >> I'm looking for people who are willing to patch their stable boxes and >> test this. This has the following changes in it: >> >> 1) Improved debugging with DEBUG_LOCKS via the new stack(9) api. >> 2) Fixed an INACTIVE leak. >> 3) Fixed several unmount races. >> 4) Fixed several nullfs unmount issues. >> 5) Some more Giant related VFS fixes and asserts. >> 6) Fixed the quota deadlock. >> >> These problems should be rare enough that most of you have not seen them. >> So just let me know if this introduces any new problems etc. I will be >> MFCing within a week. >> >> Thanks, >> Jeff > > I applied the patch to the today 6-STABLE and now testing it > on the (relatively slow, k6/266Mhz) machine, by cvs-ing the > sources and building the world. Kernel config is custom (see below > issue #2), I added DEBUG_* and WITNESS* options from your patch. > Config does not include QUOTAS. > > 1. The patch breaks the kernel ABI, even for the case when DEBUG_VFS_LOCK > is not defined. This is due to changes inside struct mount, adding mnt_ref > and rearranging several existing fields. This issue shall be at least > mentioned in release notes. Yes, you are correct. I had mentioned this to re but not in the mail here. I intend to make some changes to fix the abi breakage. > > 2. I built custom kernel with "options MAC". After some fs activity, I got > the LOR: Strange, I thought I had fixed this some time ago. I'll look into it, thanks. > > lock order reversal: > 1st 0xc1a018f0 vnode interlock (vnode interlock) @ /usr/home/kostik/work/bsd/sys/kern/vfs_subr.c:2449 > 2nd 0xc0c43144 system map (system map) @ /usr/home/kostik/work/bsd/sys/vm/vm_kern.c:295 > KDB: stack backtrace: > kdb_backtrace(0,ffffffff,c06676b0,c0667700,c0636024) at 0xc049d3c9 = kdb_backtrace+0x29 > witness_checkorder(c0c43144,9,c061fe28,127) at 0xc04a80c2 = witness_checkorder+0x582 > _mtx_lock_flags(c0c43144,0,c061fe28,127) at 0xc047b998 = _mtx_lock_flags+0x58 > _vm_map_lock(c0c430c0,c061fe28,127) at 0xc059eb46 = _vm_map_lock+0x26 > kmem_malloc(c0c430c0,1000,101,c819fbe0,c059679f) at 0xc059e0d2 = kmem_malloc+0x32 > page_alloc(c0c4d300,1000,c819fbd3,101,c06a3bf8) at 0xc0596bda = page_alloc+0x1a > slab_zalloc(c0c4d300,101,c0c4d300,c0647a64,c0c4e460) at 0xc059679f = slab_zalloc+0x9f > uma_zone_slab(c0c4d300,1,c0c4e468,0,c061f05a,8a2) at 0xc0597dec = uma_zone_slab+0xec > uma_zalloc_internal(c0c4d300,0,1,0,c0c4dc48) at 0xc0598129 = uma_zalloc_internal+0x29 > bucket_alloc(80,1,c0c380a0,0,c19ab6a4) at 0xc0595eac = bucket_alloc+0x2c > uma_zfree_arg(c0c4dc00,c19ab6a4,0) at 0xc0598483 = uma_zfree_arg+0x283 > mac_labelzone_free(c19ab6a4,c1a01828,e8,c819fc9c,c0565ad2) at 0xc055dab3 = mac_labelzone_free+0x13 > mac_vnode_label_free(c19ab6a4,c1a01828,c819fcac,c04d8766,c1a01828) at 0xc0565aaa = mac_vnode_label_free+0x6a > mac_destroy_vnode(c1a01828) at 0xc0565ad2 = mac_destroy_vnode+0x12 > vdestroy(c1a01828,c1a01828,c819fcec,c04d8142,c1a01828) at 0xc04d8766 = vdestroy+0x1c6 > vdropl(c1a01828,7,a8,c0653ee0,c1a01828) at 0xc04dad1e = vdropl+0x3e > vlrureclaim(c15e8000,c1529000,c156f000,c04d8360,c156f000) at 0xc04d8142 = vlrureclaim+0x282 > vnlru_proc(0,c819fd38,0,c04d8360,0) at 0xc04d84e3 = vnlru_proc+0x183 > fork_exit(c04d8360,0,c819fd38) at 0xc046de7d = fork_exit+0x9d > fork_trampoline() at 0xc05d33bc = fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xc819fd6c, ebp = 0 --- > > A patch to fix the LOR (seems to be relevant for CURRENT too): > > --- sys/kern/vfs_subr.c.orig Sat Mar 4 10:44:47 2006 > +++ sys/kern/vfs_subr.c Sat Mar 4 10:45:21 2006 > @@ -787,9 +787,6 @@ > VNASSERT(bo->bo_dirty.bv_root == NULL, vp, ("dirtyblkroot not NULL")); > VNASSERT(TAILQ_EMPTY(&vp->v_cache_dst), vp, ("vp has namecache dst")); > VNASSERT(LIST_EMPTY(&vp->v_cache_src), vp, ("vp has namecache src")); > -#ifdef MAC > - mac_destroy_vnode(vp); > -#endif > if (vp->v_pollinfo != NULL) { > knlist_destroy(&vp->v_pollinfo->vpi_selinfo.si_note); > mtx_destroy(&vp->v_pollinfo->vpi_lock); > @@ -801,6 +798,9 @@ > #endif > lockdestroy(vp->v_vnlock); > mtx_destroy(&vp->v_interlock); > +#ifdef MAC > + mac_destroy_vnode(vp); > +#endif > uma_zfree(vnode_zone, vp); > } > > Up to the moment > (uptime 11:09AM up 1:24, 1 user, load averages: 1.32, 1.56, 1.56) > everything else seems to be okey. > > >