Am Donnerstag, 17. Januar 2008 01:42:30 schrieb Greg KH:
> On Wed, Jan 16, 2008 at 05:18:52PM +0100, Oliver Neukum wrote:
> > Am Donnerstag, 20. Dezember 2007 16:51:59 schrieb Alan Stern:
> > > On Thu, 20 Dec 2007, Oliver Neukum wrote:
> > >
> > > > @@ -1080,20 +1081,22 @@ void usb_serial_disconnect(struct usb_in
> > > > usb_serial_console_disconnect(serial);
> > > > dbg ("%s", __FUNCTION__);
> > > >
> > > > + mutex_lock(&serial->disc_mutex);
> > > > usb_set_intfdata (interface, NULL);
> > > > - if (serial) {
> > > > - for (i = 0; i < serial->num_ports; ++i) {
> > > > - port = serial->port[i];
> > > > - if (port) {
> > > > - if (port->tty)
> > > > - tty_hangup(port->tty);
> > > > - kill_traffic(port);
> > > > - }
> > > > + /* must use extra flag, as intfdata can be reset */
> > > > + serial->disconnected = 1;
> > >
> > > This comment is misleading. It implies there is a possibility you
> > > actually could check for disconnects by looking at the value of
> > > usb_get_intfdata(), but that's completely wrong. There are about 13
> > > places in various serial drivers where this mistake is made; they all
> > > need to be fixed.
> > >
> > > Don't you also have to check the disconnect flag in serial_close()
> > > before calling usb_autopm_put_interface()?
> >
> > Where is that?
> >
> > This fixes a problem where the mos7720 driver will make io to a device from
> > which it has been logically disconnected. It does so by introducing a flag
> > by
> > which the generic usb serial code can signal the subdrivers their
> > disconnection and appropriate locking.
> >
> > Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
> >
> > I'd call this 2.6.25 material.
>
> But does it really "solve" anything? Sure, it decreases the chance of a
> race, but it can still happen (disconnect and close at the same time,
> close starts to send messages before disconnect changes theserial->disc_mutex
> "disconnected" flag).
>
> Or am I missing something else here?
Both close() and disconnect() take serial->disc_mutex
Either close() is first, then disconnect() must wait for close(). As long
as disconnect() doesn't return close() may legitimately write to the device,
or disconnect() comes first and close() will see the flag and not write.
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
