From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcel Holtmann Subject: Re: Possible problem with device_move() Date: Mon, 30 Jul 2007 08:53:30 +0200 Message-ID: <1185778420.5868.90.camel@violet> References: Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org To: Alan Stern Cc: Cornelia Huck , Linux-pm mailing list List-Id: linux-pm@vger.kernel.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