USB: ohci_hcd hang: submit vs. rmmod race
authorPete Zaitcev <zaitcev@redhat.com>
Mon, 2 Jun 2008 04:23:07 +0000 (21:23 -0700)
committerGreg Kroah-Hartman <gregkh@suse.de>
Mon, 21 Jul 2008 22:16:25 +0000 (15:16 -0700)
commit6deb270b5c60680ca9117bd545302ea6a58bad42
treea1edb9b518004c5939a29ac98a8314835b7e5166
parent6381fad77e5d44f8e0e2afffe686cb4e6fc36e71
USB: ohci_hcd hang: submit vs. rmmod race

If we do rmmod ohci_hcd while an application is doing something, the
following may happen:

- a control URB completes (in finish_urb) and the ohci's endpoint is
  set into ED_UNLINK in ed_deschedule
- same URB is (re)submitted because of the open/close loop or other
  such application behaviour
- rmmod sets the state to HC_STATE_QUESCING
- finish_unlinks happens at next SOF; normally it would set ed into
  ED_IDLE and immediately call ed_schedule (since URB had extra TDs
  queued), which sets it into ED_OPER. But the check in ed_schedule
  makes it fail with -EAGAIN (which is ignored)
- from now on we have a dead URB stuck; it cannot even be unlinked
  because the ed status is not ED_OPER, and thus start_ed_unlink is
  not invoked.

This patch removes the check. In 2.6.25, all callers check for
__ACTIVE bit before invoking ed_schedule, which is more appropriate.

Alan Stern and David Brownell approved of this (cautiously).

Signed-off-by: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/usb/host/ohci-q.c