Date: Tue, 9 Jun 2009 20:00:25 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Matthew Fleming <matthew.fleming@isilon.com> Cc: Yuri Pankov <yuri.pankov@gmail.com>, freebsd-current@freebsd.org, Paul Saab <ps@freebsd.org> Subject: Re: panic: knlist not locked, but should be Message-ID: <20090609170025.GE75569@deviant.kiev.zoral.com.ua> In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E02CC8A29@seaxch09.desktop.isilon.com> References: <20090609163005.GD75569@deviant.kiev.zoral.com.ua> <06D5F9F6F655AD4C92E28B662F7F853E02CC8A29@seaxch09.desktop.isilon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--47eKBCiAZYFK5l32
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 09, 2009 at 09:45:49AM -0700, Matthew Fleming wrote:
>=20
> > This appears to be an interaction with the recent changes to use=20
> > shared vnode locks for writes on ZFS. Hmm, I think it may be ok to=20
> > use a shared vnode lock for kevents on vnodes though. The vnode=20
> > interlock should be sufficient locking for what little work the kevent
>=20
> > filters do. As a quick hack for now the MNT_SHARED_WRITES() stuff=20
> > could avoid using shared locks 'if (!VN_KNLIST_EMPTY(vp))', but I=20
> > think the longer term fix is to not use the vnode locks for vnode
> kevents, but use the interlock instead.
>=20
> I tried (briefly) using the interlock since Isilon's vnode lock is
> cluster wide (in our 6.1 based code we got away with using Giant). This
> got me a LOR report on the interlock:
>=20
> /*
> * kqueue/VFS interaction
> */
> { "kqueue", &lock_class_mtx_sleep },
> { "struct mount mtx", &lock_class_mtx_sleep },
> { "vnode interlock", &lock_class_mtx_sleep },
> { NULL, NULL },
>=20
> since knote() will take first the list->kl_lock and then the kqueue
> lock. I didn't spend any time on it, and switched to using the vnode
> v_lock for my purposes. But someone added that lock ordering (r166421)
> for a reason.
That was me, I actually looked for the reversed order that was reported
several times on the list in 6.1-6.2 timeframe. Unfortunately, nothing
was found.
I noted in the separate letter that read filter for vnodes needs
shared vnode lock anyway.
--47eKBCiAZYFK5l32
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEARECAAYFAkoulSkACgkQC3+MBN1Mb4giiwCgueRccpaL8GJMjZAC67hn+XRa
flMAoNTqisiL7fX7KYNkyB5xysB0hBFR
=HSdM
-----END PGP SIGNATURE-----
--47eKBCiAZYFK5l32--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090609170025.GE75569>