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. -- WBR, Andrey V. Elsukov
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:28 UTC