linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, Douglas Anderson <dianders@chromium.org>,
	Guenter Roeck <linux@roeck-us.net>,
	Alan Stern <stern@rowland.harvard.edu>,
	Sumit Semwal <sumit.semwal@linaro.org>
Subject: [PATCH 4.4 14/18] usb: hub: Wait for connection to be reestablished after port reset
Date: Sun, 16 Apr 2017 10:02:37 +0200	[thread overview]
Message-ID: <20170416080213.432659632@linuxfoundation.org> (raw)
In-Reply-To: <20170416080212.713469777@linuxfoundation.org>

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Guenter Roeck <linux@roeck-us.net>

commit 22547c4cc4fe20698a6a85a55b8788859134b8e4 upstream.

On a system with a defective USB device connected to an USB hub,
an endless sequence of port connect events was observed. The sequence
of events as observed is as follows:

- Port reports connected event (port status=USB_PORT_STAT_CONNECTION).
- Event handler debounces port and resets it by calling hub_port_reset().
- hub_port_reset() calls hub_port_wait_reset() to wait for the reset
  to complete.
- The reset completes, but USB_PORT_STAT_CONNECTION is not immediately
  set in the port status register.
- hub_port_wait_reset() returns -ENOTCONN.
- Port initialization sequence is aborted.
- A few milliseconds later, the port again reports a connected event,
  and the sequence repeats.

This continues either forever or, randomly, stops if the connection
is already re-established when the port status is read. It results in
a high rate of udev events. This in turn destabilizes userspace since
the above sequence holds the device mutex pretty much continuously
and prevents userspace from actually reading the device status.

To prevent the problem from happening, let's wait for the connection
to be re-established after a port reset. If the device was actually
disconnected, the code will still return an error, but it will do so
only after the long reset timeout.

Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/core/hub.c |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2602,8 +2602,15 @@ static int hub_port_wait_reset(struct us
 		if (ret < 0)
 			return ret;
 
-		/* The port state is unknown until the reset completes. */
-		if (!(portstatus & USB_PORT_STAT_RESET))
+		/*
+		 * The port state is unknown until the reset completes.
+		 *
+		 * On top of that, some chips may require additional time
+		 * to re-establish a connection after the reset is complete,
+		 * so also wait for the connection to be re-established.
+		 */
+		if (!(portstatus & USB_PORT_STAT_RESET) &&
+		    (portstatus & USB_PORT_STAT_CONNECTION))
 			break;
 
 		/* switch to the long delay after two short delay failures */

  parent reply	other threads:[~2017-04-16  8:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-16  8:02 [PATCH 4.4 00/18] 4.4.62-stable review Greg Kroah-Hartman
2017-04-16  8:02 ` [PATCH 4.4 02/18] drm/i915: Stop using RP_DOWN_EI on Baytrail Greg Kroah-Hartman
2017-04-16  8:02 ` [PATCH 4.4 03/18] usb: dwc3: gadget: delay unmap of bounced requests Greg Kroah-Hartman
2017-04-16  8:02 ` [PATCH 4.4 05/18] MIPS: Introduce irq_stack Greg Kroah-Hartman
2017-04-16  8:02 ` [PATCH 4.4 06/18] MIPS: Stack unwinding while on IRQ stack Greg Kroah-Hartman
2017-04-16  8:02 ` [PATCH 4.4 07/18] MIPS: Only change $28 to thread_info if coming from user mode Greg Kroah-Hartman
2017-04-16  8:02 ` [PATCH 4.4 08/18] MIPS: Switch to the irq_stack in interrupts Greg Kroah-Hartman
2017-04-16  8:02 ` [PATCH 4.4 09/18] MIPS: Select HAVE_IRQ_EXIT_ON_IRQ_STACK Greg Kroah-Hartman
2017-04-16  8:02 ` [PATCH 4.4 10/18] MIPS: IRQ Stack: Fix erroneous jal to plat_irq_dispatch Greg Kroah-Hartman
2017-04-16  8:02 ` [PATCH 4.4 12/18] net/packet: fix overflow in check for priv area size Greg Kroah-Hartman
2017-04-16  8:02 ` [PATCH 4.4 13/18] blk-mq: Avoid memory reclaim when remapping queues Greg Kroah-Hartman
2017-04-16  8:02 ` Greg Kroah-Hartman [this message]
2017-04-16  8:02 ` [PATCH 4.4 15/18] net/mlx4_en: Fix bad WQE issue Greg Kroah-Hartman
2017-04-16  8:02 ` [PATCH 4.4 16/18] net/mlx4_core: Fix racy CQ (Completion Queue) free Greg Kroah-Hartman
2017-04-16  8:02 ` [PATCH 4.4 17/18] net/mlx4_core: Fix when to save some qp context flags for dynamic VST to VGT transitions Greg Kroah-Hartman
2017-04-16  8:02 ` [PATCH 4.4 18/18] ibmveth: set correct gso_size and gso_type Greg Kroah-Hartman
2017-04-16 21:28 ` [PATCH 4.4 00/18] 4.4.62-stable review Guenter Roeck
2017-04-17 18:19 ` Shuah Khan
     [not found] ` <58f36a37.cc9bdf0a.86c97.bb8a@mx.google.com>
2017-04-17 18:48   ` Shuah Khan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170416080213.432659632@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=dianders@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=stable@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=sumit.semwal@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).