Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753035AbcD0NlI (ORCPT ); Wed, 27 Apr 2016 09:41:08 -0400 Received: from mail.cybernetics.com ([173.71.130.66]:16316 "EHLO mail.cybernetics.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752039AbcD0NlH (ORCPT ); Wed, 27 Apr 2016 09:41:07 -0400 X-Greylist: delayed 306 seconds by postgrey-1.27 at vger.kernel.org; Wed, 27 Apr 2016 09:41:06 EDT Subject: Re: [PATCH] usb: hub: fix panic caused by NULL bos pointer during reset device To: "Du, Changbin" , Greg KH References: <1457428517-3099-1-git-send-email-changbin.du@intel.com> <20160426221601.GA23085@kroah.com> <0C18FE92A7765D4EB9EE5D38D86A563A05D1D704@SHSMSX103.ccr.corp.intel.com> Cc: "stern@rowland.harvard.edu" , "baolu.lu@linux.intel.com" , "chasemetzger15@gmail.com" , "balbi@ti.com" , "kborer@gmail.com" , "mjg59@coreos.com" , "jun.li@freescale.com" , "Robert.Schlabbach@gmx.net" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "joe.lawrence@stratus.com" From: Tony Battersby Message-ID: <5720C03D.5080403@cybernetics.com> Date: Wed, 27 Apr 2016 09:35:57 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <0C18FE92A7765D4EB9EE5D38D86A563A05D1D704@SHSMSX103.ccr.corp.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2906 Lines: 72 On 04/26/2016 10:53 PM, Du, Changbin wrote: >> On Tue, Mar 08, 2016 at 05:15:17PM +0800, changbin.du@intel.com wrote: >>> From: "Du, Changbin" >>> >>> This is a reworked patch based on reverted commit d8f00cd685f5 ("usb: >>> hub: do not clear BOS field during reset device"). >>> >>> The privious one caused double mem-free if run to re_enumerate label. >>> New patch title changed to distinguish from old one. And I have tested >>> it with memory debugging options. >>> >>> In function usb_reset_and_verify_device, the old BOS descriptor may >>> still be used before allocating a new one. (usb_disable_lpm function >>> uses it under the situation that it fails at usb_disable_link_state.) >>> 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. >>> >>> How to reproduce: >>> 1. connect one usb3 hub to xhci port. >>> 2. connect several lpm-capable super-speed usb disk to the hub. >>> 3. copy big files to the usb disks. >>> 4. disconnect the hub and repeat step 1-4. >>> >>> Crash log: >>> BUG: unable to handle kernel NULL pointer dereference at >>> 0000000000000010 >>> IP: [] usb_enable_link_state+0x2d/0x2f0 >>> Call Trace: >>> [] ? usb_set_lpm_timeout+0x12b/0x140 >>> [] usb_enable_lpm+0x81/0xa0 >>> [] usb_disable_lpm+0xa8/0xc0 >>> [] usb_unlocked_disable_lpm+0x2c/0x50 >>> [] usb_reset_and_verify_device+0xc3/0x710 >>> [] ? usb_sg_wait+0x13d/0x190 >>> [] usb_reset_device+0x133/0x280 >>> [] usb_stor_port_reset+0x61/0x70 >>> [] usb_stor_invoke_transport+0x88/0x520 >>> >>> Signed-off-by: Du, Changbin >>> --- >>> drivers/usb/core/hub.c | 14 +++++++++----- >>> 1 file changed, 9 insertions(+), 5 deletions(-) >> Is this patch still needed? I thought we had some other fix in this >> area... >> >> confused, >> >> greg k-h >> > Hi, Greg k-h, > Sorry for it confused you. This patch still need. This is same fix with > previous commit d8f00cd685f5 ("usb: hub: do not clear BOS field > during reset device"). But d8f00cd685f5 is buggy and reverted. This > new patch should be the final fix. > > Best Regards, > Du, Changbin > I think Greg is referring to commit 464ad8c43a9e ("usb: core : hub: Fix BOS 'NULL pointer' kernel panic"), which has already been applied upstream. It looks to me like that patch might have fixed the same problem in a different way, in which case Changbin's patch is not needed. But I haven't been involved in developing or testing that patch, so I can't say for sure. At the very least, 464ad8c43a9e conflicts with Changbin's patch. Changbin, can you take a look at 464ad8c43a9e and see if that fixes the same problem that your patch did? Thanks, Tony Battersby