From owner-freebsd-fs@FreeBSD.ORG Mon Oct 3 16:20:53 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C626B106567C for ; Mon, 3 Oct 2011 16:20:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 4C6AC8FC0C for ; Mon, 3 Oct 2011 16:20:52 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p93G1jtH067234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Oct 2011 19:01:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id p93G1jlN073675; Mon, 3 Oct 2011 19:01:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id p93G1jFg073674; Mon, 3 Oct 2011 19:01:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 3 Oct 2011 19:01:45 +0300 From: Kostik Belousov To: Lev Serebryakov Message-ID: <20111003160145.GP1511@deviant.kiev.zoral.com.ua> References: <1258376930.20111002193223@serebryakov.spb.ru> <228926402.20111002231459@serebryakov.spb.ru> <349860851.20111003113417@serebryakov.spb.ru> <4E8986F0.3050007@freebsd.org> <1223820108.20111003161859@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mxmMT58/z/5uKrU0" Content-Disposition: inline In-Reply-To: <1223820108.20111003161859@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Lawrence Stewart , fs@freebsd.org Subject: Re: code in GEOM thread could not use vnode API (Was: alq_open_flags() panics in _mtx_lock_flags()) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 16:20:53 -0000 --mxmMT58/z/5uKrU0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 03, 2011 at 04:18:59PM +0400, Lev Serebryakov wrote: > Hello, Lawrence. > You wrote 3 =CF=CB=D4=D1=C2=D2=D1 2011 =C7., 13:57:04: >=20 > > I know nothing about VFS, but wonder if it's something to do with the > > credentials you pass in? > They looks Ok. Not NULL, at least :) I'm passing > "curtrhead->td_ucred". >=20 > > Lev, are you able to share your code with us? > Yes, of course. Minimal code, which trigger this error, attached. > Build, load module and PANIC! >=20 > This is geom_zero module, which try to create ALQ with name > "/var/log/zero.alq.log" on it load (not creation! So, you don't need > even create such GEOM!). Please note, that "init" callback of GEOM > class is called in g_event GEOM thread. >=20 > Code is for 9.0/10.0 >=20 > My code is rewritten with usage of working thread already, and it > works without any panic. But worker thread looks like overkill for > simple case "write 24 bytes record to ALQ for each BIO" to me. >=20 > So I could prove, that this code PANIC because alq_open_flags() is > called from one of three GEOM threads. Look at the body of e.g. g_io_schedule_down(), the THREAD_NO_SLEEPING(); call right before the call to geom start method. Basically, you cannot use any kernel subsystem in the context of the up/down threads that could sleep. This includes VFS, VM and everything that is layered on top of it. The decision is deliberate. Up and down shall only schedule the processing, or perform the fast processing. BTW, it must be obvious that trying to perform any VFS operation from geom up or down causes deadlock. --mxmMT58/z/5uKrU0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6J3GkACgkQC3+MBN1Mb4iblQCfWiHwQSBUgtuilPBx2j4bjEEU /4MAn16LlHk78mVV88fgIEaw+aX/pBYy =igD2 -----END PGP SIGNATURE----- --mxmMT58/z/5uKrU0--