From owner-freebsd-current@FreeBSD.ORG Tue Jun 9 17:00:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EF2810656C6; Tue, 9 Jun 2009 17:00:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id B208A8FC21; Tue, 9 Jun 2009 17:00:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1ME4gW-0006kN-OE; Tue, 09 Jun 2009 20:00:29 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n59H0PPn096336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 20:00:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n59H0Psq062628; Tue, 9 Jun 2009 20:00:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n59H0PoD062627; Tue, 9 Jun 2009 20:00:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 9 Jun 2009 20:00:25 +0300 From: Kostik Belousov To: Matthew Fleming Message-ID: <20090609170025.GE75569@deviant.kiev.zoral.com.ua> References: <20090609163005.GD75569@deviant.kiev.zoral.com.ua> <06D5F9F6F655AD4C92E28B662F7F853E02CC8A29@seaxch09.desktop.isilon.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="47eKBCiAZYFK5l32" Content-Disposition: inline In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E02CC8A29@seaxch09.desktop.isilon.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.1 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1ME4gW-0006kN-OE b3d00f87743d93f0128de86361a6747a X-Terabit: YES Cc: Yuri Pankov , freebsd-current@freebsd.org, Paul Saab Subject: Re: panic: knlist not locked, but should be X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 17:00:33 -0000 --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--