On Thu, Oct 18, 2018 at 1:15 PM Bart Van Assche <[email protected]> wrote: > > On Thu, 2018-10-18 at 12:38 -0700, Alexander Duyck wrote: > > Basically if somebody loads a driver the dev->driver becomes set. If a > > driver is removed it will clear dev->driver and set driver_data to > > 0/NULL. That is what I am using as a mutex to track it in conjunction > > with the device mutex. Basically if somebody attempts to attach a driver > > before we get there we just exit and don't attempt to load this driver. > > I don't think that the above matches your code. __device_attach() does not > set the dev->driver pointer before scheduling an asynchronous probe. Only > dev->driver_data gets set before the asynchonous probe is scheduled. Since > driver_detach() only iterates over devices that are in the per-driver klist > it will skip all devices for which an asynchronous probe has been scheduled > but __device_attach_async_helper() has not yet been called. My conclusion > remains that this patch does not prevent a driver pointer to become invalid > concurrently with __device_attach_async_helper() dereferencing the same > driver pointer. > > Bart.
I see what you are talking about now. Actually I think this was an existing issue before my patch even came into play. Basically the code as it currently stands is device specific in terms of the attach and release code. I wonder if we shouldn't have the async_synchronize_full call in __device_release_driver moved down and into driver_detach before we even start the for loop. Assuming the driver is no longer associated with the bus that should flush out all devices so that we can then pull them out of the devices list at least. I may look at adding an additional bitflag to the device struct to indicate that it has a driver attach pending. Then for things like races between any attach and detach calls the logic becomes pretty straight forward. Attach will set the bit and provide driver data, detach will clear the bit and the driver data. If a driver loads in between it should clear the bit as well. I'll work on it over the next couple days and hopefully have something ready for testing/review early next week. Thanks. - Alex
