Re: minor GEOM disk API change coming

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_at_FreeBSD.ORG