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.

Kenneth Merry
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to