On Thu, 15 Mar 2012, Ming Lei wrote:
> On Thu, Mar 15, 2012 at 12:04 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>
> > Is there any way to reproduce this?
> >
> > It seems to be saying that usb_stor_pre_reset() was called twice
> > without usb_stor_post_reset() being called in between, because the
> > post_reset routine is where the lock gets released. �I don't know of
> > any way that could happen.
>
> Looks it is a device with multiple usb mass interfaces, care to
> post the 'lsusb -v' of the device?
>
> If so, the following patch should remove the warning.
>
> diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
> index c18538e..1c209a0 100644
> --- a/drivers/usb/storage/usb.c
> +++ b/drivers/usb/storage/usb.c
> @@ -194,11 +194,13 @@ EXPORT_SYMBOL_GPL(usb_stor_reset_resume);
> int usb_stor_pre_reset(struct usb_interface *iface)
> {
> struct us_data *us = usb_get_intfdata(iface);
> + int if_num = (int)(iface -
> + us->pusb_dev->actconfig->interface[0]);
>
> US_DEBUGP("%s\n", __func__);
>
> /* Make sure no command runs during the reset */
> - mutex_lock(&us->dev_mutex);
> + mutex_lock_nested(&us->dev_mutex, if_num);
> return 0;
> }
> EXPORT_SYMBOL_GPL(usb_stor_pre_reset);
No, it won't fix the problem. It will work once, say when the driver
for interface 0 does a reset and calls the routine for interface 1.
But then what will happen when the driver for interface 1 does a reset
and calls the routine for interface 0?
I don't know how to prevent lockdep from complaining about this sort of
thing. It can't lead to a genuine deadlock, because a thread never
tries to acquire more than one of these dev_mutex things unless it's
already holding the device lock.
Peter, any ideas?
Alan Stern
--
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
