patch

Roman Kagan rkagan at mail.ru
Tue Feb 1 01:38:43 EST 2005


  Hi Duncan,

On Mon, Jan 31, 2005 at 09:41:32PM +0100, Duncan Sands wrote:
> > On Fri, Jan 28, 2005 at 03:33:26PM +0100, Duncan Sands wrote:
> > > > +	down(&usbatm_driver_list_sem);
> > > > +	list_for_each_entry(driver, &usbatm_driver_list, driver_list)
> > > > +		if (usb_match_id(intf, driver->id_table))
> > > > +			break;
> > > > +	up(&usbatm_driver_list_sem);
> > > > +
> > > >         if (!driver) {
> > > 
> > > if there's no matching entry, driver is not NULL, it is (more or less)
> > > the list head...  I'll take care of it.
> > 
> > The matching entry is there, otherwise the USB core wouldn't call
> > driver's probe, and it holds a reference to the driver's .owner so no
> > deregister can happen here.
> 
> You are assuming that the usbatm_driver has the same list of ids as the usb_driver.

Yes, at the time I wrote that I hadn't yet caught up with the CVS so I
was talking of how it was done in the patch I sent.  There usb_driver's
ids came from usbatm_driver's, and this condition was ensured by
usbatm_(de)register.

> > Umm, probably except for a small window between list manipulation and
> > usb_(de)register in usbatm_(de)register.  It can be fixed by moving the
> > release of the semaphore after the usb_(de)register.
> 
> How do you mean?  If you first register the usbatm driver, and only then the usb
> driver there should be no problem (and that is how it should be done - I should
> document this).

Right, I just looked at my usbatm_deregister and didn't realize that
moving usb_deregister before deleting the usbatm_driver from the list
solves the problem.

Cheers,
  Roman.



More information about the Usbatm mailing list