Re: Mutex deadlock from garmin_close in garmin_gps.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am Sonntag 05 April 2009 16:40:03 schrieb Alan Stern:
> On Sat, 4 Apr 2009, Oliver Neukum wrote:
> > > In any case, shouldn't the generic layer contain pre_reset and
> > > post_reset routines?  And shouldn't these routines be listed in the
> > > usb_driver structure for each of the subdrivers?
> >
> > What could generic methods do?
>
> Not much, I guess.  Check whether the device file is open and call
> kill_traffic() if it is?  But I'm not familiar with all the ins and
> outs of these drivers.

We couldn't limit this to the case of an opened interface,
as some drivers schedule interrupt URBs always and we'd
need a way to signal drivers why traffic is killed, lest they
start error handling procedures.

> BTW, I'm concerned about that usb-serial.c patch posted earlier.  In
> particular, does serial_open() hold disc_mutex long enough?  What
> happens if a disconnect occurs while serial_open() is waiting to
> acquire port->mutex?  Do you think the calls to
> usb_autopm_get_interface() and serial->type->open() should also be
> protected by disc_mutex?

Yes. usb_autopm_get_interface() must be protected or the counters get out of 
sync.

	Regards
		Oliver

--
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

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux