From: <gregkh@linuxfoundation.org>
To: changbin.du@intel.com, gregkh@linuxfoundation.org
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "usb: hub: do not clear BOS field during reset device" has been added to the 3.14-stable tree
Date: Sun, 14 Feb 2016 11:46:07 -0800 [thread overview]
Message-ID: <145547916799236@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
usb: hub: do not clear BOS field during reset device
to the 3.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
usb-hub-do-not-clear-bos-field-during-reset-device.patch
and it can be found in the queue-3.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d8f00cd685f5c8e0def8593e520a7fef12c22407 Mon Sep 17 00:00:00 2001
From: "Du, Changbin" <changbin.du@intel.com>
Date: Mon, 18 Jan 2016 21:02:42 +0800
Subject: usb: hub: do not clear BOS field during reset device
From: Du, Changbin <changbin.du@intel.com>
commit d8f00cd685f5c8e0def8593e520a7fef12c22407 upstream.
In function usb_reset_and_verify_device, the old BOS descriptor may
still be used before allocating a new one. (usb_unlocked_disable_lpm
function uses it under the situation that it fails to disable lpm.)
So we cannot set the udev->bos to NULL before that, just keep what it
was. It will be overwrite when allocating a new one.
Crash log:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000010
IP: [<ffffffff8171f98d>] usb_enable_link_state+0x2d/0x2f0
Call Trace:
[<ffffffff8171ed5b>] ? usb_set_lpm_timeout+0x12b/0x140
[<ffffffff8171fcd1>] usb_enable_lpm+0x81/0xa0
[<ffffffff8171fdd8>] usb_disable_lpm+0xa8/0xc0
[<ffffffff8171fe1c>] usb_unlocked_disable_lpm+0x2c/0x50
[<ffffffff81723933>] usb_reset_and_verify_device+0xc3/0x710
[<ffffffff8172c4ed>] ? usb_sg_wait+0x13d/0x190
[<ffffffff81724743>] usb_reset_device+0x133/0x280
[<ffffffff8179ccd1>] usb_stor_port_reset+0x61/0x70
[<ffffffff8179cd68>] usb_stor_invoke_transport+0x88/0x520
Signed-off-by: Du, Changbin <changbin.du@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/core/hub.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -5225,7 +5225,6 @@ static int usb_reset_and_verify_device(s
usb_set_usb2_hardware_lpm(udev, 0);
bos = udev->bos;
- udev->bos = NULL;
/* Disable LPM and LTM while we reset the device and reinstall the alt
* settings. Device-initiated LPM settings, and system exit latency
@@ -5334,8 +5333,11 @@ done:
usb_set_usb2_hardware_lpm(udev, 1);
usb_unlocked_enable_lpm(udev);
usb_enable_ltm(udev);
- usb_release_bos_descriptor(udev);
- udev->bos = bos;
+ /* release the new BOS descriptor allocated by hub_port_init() */
+ if (udev->bos != bos) {
+ usb_release_bos_descriptor(udev);
+ udev->bos = bos;
+ }
return 0;
re_enumerate:
Patches currently in stable-queue which might be from changbin.du@intel.com are
queue-3.14/usb-hub-do-not-clear-bos-field-during-reset-device.patch
reply other threads:[~2016-02-14 19:46 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=145547916799236@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=changbin.du@intel.com \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.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