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 k...@freebsd.org _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
