Cornelia and Marcel: The only places in the kernel that call device_move() are in drivers/s390/cio/device.c and net/bluetooth/rfcomm/tty.c, so I want to check with the two of you. I'm in the midst of changing the Power Management core to make it acquire the device semaphore of every device during a suspend and resume. The order of acquisition is the order of device registration, which normally agrees with the way locks are acquired when going through the device tree (i.e., parents before children). But when you call device_move() that might no longer be true. If a device is moved so that its new parent was registered _after_ it was, then the two orders will disagree. This raises the possibility of a deadlock if any thread ever tries to lock the device while holding the new parent's lock -- as might happen during an unregistration, for example. Can you tell whether this will ever cause a problem? Or is it known to be safe because whenever you call device_move(), the new parent was registered before the device being moved? Thanks, Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
