On 11/30/16 10:37, Laurent Pinchart wrote: >>> To fix this properly I think we need to make the bridge object refcounted, >>> > > with a release callback to signal to the bridge driver that memory can be >>> > > freed. The refcount should be increased in of_drm_find_bridge(), and >>> > > decreased in a new drm_bridge_put() function (the "fun" part will be to >>> > > update drivers to call that :-S). >> > >> > I think another option would be to find and attach the bridge object >> > atomically by holding the bridge_lock until the try_module_get() has >> > succeeded. >> > >> > AFAIU, if the module unload is triggered while holding the bridge_lock >> > but before the try_module_get() call, then try_module_get() would return >> > false and the attach call will return failure. > This would require combining lookup and attach in all cases. I'm not sure that > would be very convenient for drivers. Keeping the two operations separate > would be more flexible. > That could be avoided if of_drm_find_bridge() would copy the content of bridge object, in stead of providing a pointer. The attach call could then search for the bridge object again before continuing. But still in the end the impact to individual drivers would be equal to adding a simple drm_bridge_put() call. Probably better to go forward with your suggestion. Even adding the drm_bridge_put() would not be necessary in most cases if we would add a devm version of getting the bridge object. In 99% of cases the device probe will fail if the bridge attach fails, and bridge object refcount would return to zero automatically. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
