On Wed, 1 Aug 2007, Paul Mackerras wrote: > Alan Stern writes: > > > I think this is subject to the same weakness Dmitry mentions: By the > > time the driver would block on the new rwsem, it has already started > > mucking with the device. Worse yet, it may hold a mutex that the > > suspend method needs, thereby deadlocking the suspend. (That's what > > would happen with serio->drv_mutex in the input layer.) > > > > Maybe the best answer is simply to fail all attempts at device > > registration while a suspend is underway. At least that is a known > > error path which drivers are prepared (in theory) to deal with. It > > could be implemented quite easily with an rwsem, by making the > > registration code use down_read_trylock. > > What about making a list of devices that drivers have attempted to > register? While the system is suspending, if a driver attempts to > register a device, put it on a list and return success. Then, after > resuming, run through the list and actually process them. I'm not sure it's safe to lie to drivers, telling them that their device has been registered when in fact it hasn't. For instance, what if the driver then calls device_create_file()? Safe or not, it certainly isn't transparent and therefore isn't a good thing to do. Of course, the problem with my approach is that it puts the burden on drivers of blocking threads which want to register devices. This turns out to be distressingly difficult -- easier just to let them fail. I was hoping to find a centralized solution but apparently there isn't one. A better approach would be to fail registrations only if the parent is already suspended. Maybe that can be made to work... but I'm doubtful. (What if the parent gets suspended _during_ the child's registration?) > I guess removal during suspend/resume should remove the list entry, if > the device is one of the ones on the list. Otherwise, is there a > problem with letting removals proceed during suspend/resume? (In > general removal can be notified after the device has physically > disappeared IIRC, so driver unbind functions have to avoid touching > the device or at least be prepared to deal with it not responding.) I don't think removal during suspend poses a serious problem. It can never lead to a situation where a suspended parent has an unsuspended child, which is what we need to avoid. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
