From owner-freebsd-fs@FreeBSD.ORG Mon Oct 3 16:27:38 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 B51811065673; Mon, 3 Oct 2011 16:27:38 +0000 (UTC) (envelope-from lev@freebsd.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4E9848FC13; Mon, 3 Oct 2011 16:27:38 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:906c:6af3:5301:18c6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 6F18D4AC1C; Mon, 3 Oct 2011 20:27:36 +0400 (MSD) Date: Mon, 3 Oct 2011 20:27:28 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1298204673.20111003202728@serebryakov.spb.ru> To: Kostik Belousov In-Reply-To: <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> <20111003160145.GP1511@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable 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:27:38 -0000 Hello, Kostik. You wrote 3 =CF=CB=D4=D1=C2=D2=D1 2011 =C7., 20:01:45: > 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. VM too? Allocating of new element to put into working queue is prohibited? It is what (almost) every GEOM class does. Even geom_nop() allocate new struct bio from g_down thread. > The decision is deliberate. Up and down shall only schedule the processin= g, > or perform the fast processing. Schedule is impossible without memory allocations in most cases... > BTW, it must be obvious that trying to perform any VFS operation from geom > up or down causes deadlock. Could cause. alq uses its own thread for "real" VFS operations, and open() was called from g_event, not g_up/g_down... BTW, nothing stops me from calling msleep() in g_event thread (to wait when working thread stops on exit, for example). And, again, it is what many "base" geom classes uses, even if they use working thread concept. And panic due to NULL pointer derefernce is not best way to indicate, that logic is broken (but it is not broken in this case, as it is impossible to create consumer for occupied geom with file system) :) --=20 // Black Lion AKA Lev Serebryakov