Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 4 Mar 2006 11:15:22 +0200
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Jeff Roberson <jroberson@chesapeake.net>
Cc:        stable@freebsd.org
Subject:   Re: VFS MFC testers wanted
Message-ID:  <20060304091522.GD37572@deviant.kiev.zoral.com.ua>
In-Reply-To: <20060303153833.Q557@10.0.0.1>
References:  <20060303153833.Q557@10.0.0.1>

next in thread | previous in thread | raw e-mail | index | archive | help

--HWvPVVuAAfuRc6SZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
>=20
> http://www.chesapeake.net/~jroberson/vfsmfc.diff
>=20
> I'm looking for people who are willing to patch their stable boxes and=20
> test this.  This has the following changes in it:
>=20
> 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.
>=20
> These problems should be rare enough that most of you have not seen them.=
=20
> So just let me know if this introduces any new problems etc.  I will be=
=20
> MFCing within a week.
>=20
> 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.

2. I built custom kernel with "options MAC". After some fs activity, I got
the LOR:

lock order reversal:
 1st 0xc1a018f0 vnode interlock (vnode interlock) @ /usr/home/kostik/work/b=
sd/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 =3D kdb_=
backtrace+0x29
witness_checkorder(c0c43144,9,c061fe28,127) at 0xc04a80c2 =3D witness_check=
order+0x582
_mtx_lock_flags(c0c43144,0,c061fe28,127) at 0xc047b998 =3D _mtx_lock_flags+=
0x58
_vm_map_lock(c0c430c0,c061fe28,127) at 0xc059eb46 =3D _vm_map_lock+0x26
kmem_malloc(c0c430c0,1000,101,c819fbe0,c059679f) at 0xc059e0d2 =3D kmem_mal=
loc+0x32
page_alloc(c0c4d300,1000,c819fbd3,101,c06a3bf8) at 0xc0596bda =3D page_allo=
c+0x1a
slab_zalloc(c0c4d300,101,c0c4d300,c0647a64,c0c4e460) at 0xc059679f =3D slab=
_zalloc+0x9f
uma_zone_slab(c0c4d300,1,c0c4e468,0,c061f05a,8a2) at 0xc0597dec =3D uma_zon=
e_slab+0xec
uma_zalloc_internal(c0c4d300,0,1,0,c0c4dc48) at 0xc0598129 =3D uma_zalloc_i=
nternal+0x29
bucket_alloc(80,1,c0c380a0,0,c19ab6a4) at 0xc0595eac =3D bucket_alloc+0x2c
uma_zfree_arg(c0c4dc00,c19ab6a4,0) at 0xc0598483 =3D uma_zfree_arg+0x283
mac_labelzone_free(c19ab6a4,c1a01828,e8,c819fc9c,c0565ad2) at 0xc055dab3 =
=3D mac_labelzone_free+0x13
mac_vnode_label_free(c19ab6a4,c1a01828,c819fcac,c04d8766,c1a01828) at 0xc05=
65aaa =3D mac_vnode_label_free+0x6a
mac_destroy_vnode(c1a01828) at 0xc0565ad2 =3D mac_destroy_vnode+0x12
vdestroy(c1a01828,c1a01828,c819fcec,c04d8142,c1a01828) at 0xc04d8766 =3D vd=
estroy+0x1c6
vdropl(c1a01828,7,a8,c0653ee0,c1a01828) at 0xc04dad1e =3D vdropl+0x3e
vlrureclaim(c15e8000,c1529000,c156f000,c04d8360,c156f000) at 0xc04d8142 =3D=
 vlrureclaim+0x282
vnlru_proc(0,c819fd38,0,c04d8360,0) at 0xc04d84e3 =3D vnlru_proc+0x183
fork_exit(c04d8360,0,c819fd38) at 0xc046de7d =3D fork_exit+0x9d
fork_trampoline() at 0xc05d33bc =3D fork_trampoline+0x8
--- trap 0x1, eip =3D 0, esp =3D 0xc819fd6c, ebp =3D 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 =3D=3D 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 !=3D 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);
 }
=20
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.



--HWvPVVuAAfuRc6SZ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (FreeBSD)

iD8DBQFECVqpC3+MBN1Mb4gRAn5mAKDkwpWNTNMOM6gNj1r+/IbEkGEFkQCfV1cf
mSRoREvKO/gu6Afw/DrAB+E=
=VgJf
-----END PGP SIGNATURE-----

--HWvPVVuAAfuRc6SZ--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060304091522.GD37572>