VFS MFC testers wanted

Jeff Roberson jroberson at chesapeake.net
Sun Mar 5 23:51:11 UTC 2006


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.
>
>
>


More information about the freebsd-stable mailing list