Re: [BUG, Regression, bisected] USB mouse causes bug on 1stinsert, ignored on 2nd insert, lsusb stuck at usbdev_open

[Greg KH]

On Tue, Sep 21, 2010 at 06:55:36PM +0200, Jiri Kosina wrote:
> On Tue, 21 Sep 2010, Greg KH wrote:
> 
> > > > I have just found out that it's actually CONFIG_USB_DYNAMIC_MINORS which 
> > > > makes the difference. When unset, the problem doesn't trigger, and 
> > > > usb_find_interface() always returns the proper interface. When 
> > > > CONFIG_USB_DYNAMIC_MINORS is being used, the oops happen.
> > > > 
> > > > I'll look into that.
> > > 
> > > Apparently the problem is that intf->minors doesn't get initialized 
> > > properly.  This patch should fix it.  Everybody, please try it out.
> > 
> > Wow, what happened to suddenly cause this?  Nothing has changed here in
> > a long time.
> > 
> > wierd.
> 
> It doesn't hit you if you are calling usb_register_dev() for all the 
> instances you have, as the first device will have minor '0', the second 
> one '1', etc.
> 
> But if you are calling usb_find_interface() for devices that have never 
> been registered through usb_register_dev(), then you have a problem, as 
> usb_find_interface() will match those unregistered devices (as minor == 0 
> in such cases).
> 
> This is probably quite rare scenario, and hiddev (which might be the only 
> in-kernel driver doing this?) has moved to usb_find_interface() only 
> recently.

Ah, ok, that makes sense, I never thought of someone calling that
function if they had never registered a device :)

When did hiddev make this change?  We need to know that for the -stable
backport of this patch.

Alan, care to resend the patch in a format I can apply it?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/