Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Jun 2012 23:23:56 -0600
From:      "Kenneth D. Merry" <ken@FreeBSD.org>
To:        "Andrey V. Elsukov" <ae@FreeBSD.org>
Cc:        current@FreeBSD.org
Subject:   Re: minor GEOM disk API change coming
Message-ID:  <20120622052356.GA28831@nargothrond.kdm.org>
In-Reply-To: <4FE37CD2.2060001@FreeBSD.org>
References:  <20120621042925.GA44903@nargothrond.kdm.org> <4FE3435F.9080400@FreeBSD.org> <20120621164853.GA37027@nargothrond.kdm.org> <4FE37CD2.2060001@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120622052356.GA28831>