From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756662AbcECVSa (ORCPT ); Tue, 3 May 2016 17:18:30 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:60077 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756342AbcECVS1 (ORCPT ); Tue, 3 May 2016 17:18:27 -0400 Date: Tue, 3 May 2016 14:18:26 -0700 From: Greg KH To: Tony Battersby Cc: "Du, Changbin" , "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" Subject: Re: [PATCH] usb: hub: fix panic caused by NULL bos pointer during reset device Message-ID: <20160503211826.GA10162@kroah.com> References: <1457428517-3099-1-git-send-email-changbin.du@intel.com> <20160426221601.GA23085@kroah.com> <0C18FE92A7765D4EB9EE5D38D86A563A05D1D704@SHSMSX103.ccr.corp.intel.com> <5720C03D.5080403@cybernetics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5720C03D.5080403@cybernetics.com> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 27, 2016 at 09:35:57AM -0400, Tony Battersby wrote: > 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? Given the lack of response here, I've dropped this from my queue. If it's still needed, someone must resend it. thanks, greg k-h