From owner-freebsd-current@FreeBSD.ORG Fri Jun 22 05:24:03 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0827E10659DB; Fri, 22 Jun 2012 05:24:03 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id BE7E68FC16; Fri, 22 Jun 2012 05:24:02 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q5M5NutN031317; Thu, 21 Jun 2012 23:23:56 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q5M5NuKn031316; Thu, 21 Jun 2012 23:23:56 -0600 (MDT) (envelope-from ken) Date: Thu, 21 Jun 2012 23:23:56 -0600 From: "Kenneth D. Merry" To: "Andrey V. Elsukov" Message-ID: <20120622052356.GA28831@nargothrond.kdm.org> References: <20120621042925.GA44903@nargothrond.kdm.org> <4FE3435F.9080400@FreeBSD.org> <20120621164853.GA37027@nargothrond.kdm.org> <4FE37CD2.2060001@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FE37CD2.2060001@FreeBSD.org> User-Agent: Mutt/1.4.2i Cc: current@FreeBSD.org Subject: Re: minor GEOM disk API change coming 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: Fri, 22 Jun 2012 05:24:03 -0000 On Thu, Jun 21, 2012 at 23:58:10 +0400, Andrey V. Elsukov wrote: > On 21.06.2012 20:48, Kenneth D. Merry wrote: > >>> In this case, the GEOM disk class instance has been created by > >>> disk_create(), and the taste of the disk is queued in the GEOM > >>> event queue. > >>> > >>> While that event is queued, the da(4) instance goes away. When the > >>> open call comes into the da(4) driver, it dereferences the freed > >>> (but non-NULL) peripheral pointer provided by GEOM, which results > >>> in a panic. > >> > >> I think this situation is very specific for the GEOM_DISK class, and > >> this callback will be less useful for other classes. > >> Does g_cancel_event() cannot help you prevent tasting? > > > > Calling g_cancel_event(), for instance from disk_gone(), would not > > completely close the race condition. It can't cancel an event that is > > already in progress, and it is possible for the peripheral to go away while > > the event is marked in progress but before the taste gets far enough into > > daopen() to acquire a reference to the peripheral. > > If i understand correctly your patch, you acquires a reference to the > periph and release it when g_destroy_provider finished. What if you will > queue some custom event from the disk_gone() that will call > cddiskgonecb()? Does it close the race? This event will be executed > after the taste completes. That still would not close the race. It would still be possible for another context to come along and open the device at any point. Ken -- Kenneth Merry ken@FreeBSD.ORG