Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > On Fri, 23 Apr 2010, Eric W. Biederman wrote: > >> Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: >> >> > Eric: >> > >> > This looks like it's up your alley. >> >> I took a quick look at the code and this actually looks like a >> legitimate warning. >> >> I may be wrong but it looks like the write method >> set_bConfigurationValue disable it's current usb device and attempts >> to remove the bConfigurationValue sysfs file, and in doing so waits >> for the write to complete. aka deadlock. > > No, it doesn't do that. The write method might _unconfigure_ the USB > device, but it would not disable the device and it would not try to > remove the bConfigurationValue file. > > Here's the relevant part of the stack dump: > > [<ffffffff811785ba>] sysfs_addrm_finish+0x36/0x55 > [<ffffffff81176818>] sysfs_hash_and_remove+0x53/0x6a > [<ffffffff811799b1>] sysfs_remove_group+0x91/0xca > [<ffffffff812f2b45>] dpm_sysfs_remove+0x19/0x1b > [<ffffffff812ebbdd>] device_del+0x4c/0x1ab > [<ffffffff812ebd70>] device_unregister+0x34/0x5b > [<ffffffff8135207f>] usb_remove_ep_devs+0x23/0x2f > [<ffffffff8134adb9>] remove_intf_ep_devs+0x37/0x4d > [<ffffffff8134b00b>] usb_disable_device+0xc4/0x1d8 > [<ffffffff8134cd62>] usb_set_configuration+0x28d/0x685 > [<ffffffff8107df48>] ? mark_held_locks+0x52/0x70 > [<ffffffff8147ace1>] ? _raw_spin_unlock_irqrestore+0x47/0x56 > [<ffffffff813519ef>] set_bConfigurationValue+0x5e/0x88 > > This shows that set_bConfigurationValue indirectly calls > device_unregister() not for its own device, but for various children > (the interface ep devices). Not only are these different device > structures, they don't even have a bConfigurationValue attribute. > > (Note that it _is_ possible for a write to bConfigurationValue for one > device to unregister a child device that _does_ have a > bConfigurationValue attribute. But that's not what occurred here.) > >> This might also be one of the false positives I reworked the code in >> 2.6.34 to fix, by putting different attributes in different sysfs >> classes but it doesn't look like it. > > Are you sure? It kind of looks like it to me. Maybe the fix wasn't > present in the kernel Dave was running. Given your description this does look like a false positive. Rereading the code it looks like my error was not in reading into usb_disable_device and realizing that the children of the disabled device would be removed. I think we will still have a false positive in 2.6.34 if one the children also has an instance of the bConfigurationValue attribute. As all attributes are made to live in the same lockdep class. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
