Re: Possible problem with device_move()

[Marcel Holtmann <marcel@holtmann.org>]

Hi Alan,

> 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.

the Bluetooth subsystem or the RFCOMM TTY code to be more precise uses
device_move() to attach an registered /dev/rfcommX device node (but not
connected) to the appropriate Bluetooth adapter and the low-level
piconet connection when you open (and thus connect) it.

So mainly we re-parent the TTY to the Bluetooth connection and after the
connection terminates we re-parent it to the virtual tree (NULL).

Regards

Marcel