On Mon, Jan 20, 2014 at 03:51:28PM -0800, Greg KH wrote: > On Mon, Jan 20, 2014 at 11:16:03PM +0000, Russell King - ARM Linux wrote: > > I don't believe the driver model has any locking to prevent a drivers > > ->probe function running concurrently with it's ->remove function for > > two (or more) devices. > > The bus prevents this from happening. > > > The locking against this is done on a per-device basis, not a per-driver > > basis. > > No, on a per-bus basis. I don't see it. Let's start from driver_register(). This takes no locks and calls bus_add_driver(). This also takes no locks and calls driver_attach(). This walks the list of devices calling __driver_attach() for each. __driver_attach() tries to match the device against the driver, locks the parent device if one exists, and the device which is about to be probed. It then calls driver_probe_device(). driver_probe_device() inserts a runtime barrier and calls really_probe(). really_probe() ultimately calls either the bus ->probe method or the driver ->probe method. At no point in that sequence do I see anything which does any locking on a per-driver basis. Let's look at device_add(). device_add() calls bus_probe_device(), which then calls device_attach(). device_attach() takes the device's lock, and walks the list of drivers calling __device_attach() on each driver. This then calls down into driver_probe_device(), and the path is the same as the above. I don't see any per-driver locking here either. I've checked the klist stuff, don't see anything there. Ditto for bus_for_each_drv(). If you think there's a per-driver lock that's held over probes or removes, please point it out. I'm fairly certain that there isn't, because we have to be able to deal with recursive probes (yes, we've had to deal with those in the past.) -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was "up to 13.2Mbit". -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |