From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753279AbcCRW6p (ORCPT ); Fri, 18 Mar 2016 18:58:45 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:45850 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751822AbcCRW6g (ORCPT ); Fri, 18 Mar 2016 18:58:36 -0400 Date: Fri, 18 Mar 2016 15:58:35 -0700 From: Greg KH To: Linus Torvalds , Nicolai Stange Cc: Peter Chen , Philipp Zabel , Alan Stern , Rob Herring , Arnd Bergmann , Andrew Morton , Linux Kernel Mailing List , USB list Subject: Re: [GIT PULL] USB driver patches for 4.6-rc1 Message-ID: <20160318225835.GA6200@kroah.com> References: <20160317000918.GA12818@kroah.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 18, 2016 at 03:51:34PM -0700, Linus Torvalds wrote: > On Fri, Mar 18, 2016 at 2:58 PM, Linus Torvalds > wrote: > > > > Yeah, the bisect is now solidly in the usb part. > > The commit that ends up being marked bad is odd, but there it is: > 69bec7259853 "USB: core: let USB device know device node". > > Very odd, but I tested multiple times: I'm typing this on > d883f52e1f6d, and everything is fine. On 69bec7259853, I can't type. > > Note that when I say "I can't type", it's the early boot disk > encryption password. And maybe there's an oops there, but I can't see > it, and I can't log it. > > I don't even have CONFIG_OF enabled, so I don't see what difference > that patch would make. But it makes some difference. > > I'll double-check by reverting it on top of current git (it does seem > to at least revert cleanly), I haven't done that yet. But adding the > people involved in that commit to the discussion to see if anybody > sees anything. Yes, people did report issues with that yesterday, and I queued up a patch for it, it's attached below, but I didn't think it would cause any issues with non-OF systems either. I wanted to give it a few days testing in linux-next before sending it to you, but can do so now if you want. thanks, greg k-h --YiEDa0DAkWCtVeE4 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0002-usb-core-usb_alloc_dev-fix-setting-of-portnum.patch" >>From 7222c832254a75dcd67d683df75753d4a4e125bb Mon Sep 17 00:00:00 2001 From: Nicolai Stange Date: Thu, 17 Mar 2016 23:53:02 +0100 Subject: [PATCH 2/5] usb/core: usb_alloc_dev(): fix setting of ->portnum With commit 69bec7259853 ("USB: core: let USB device know device node"), the port1 argument of usb_alloc_dev() gets overwritten as follows: ... usb_alloc_dev(..., unsigned port1) { ... if (!parent->parent) { port1 = usb_hcd_find_raw_port_number(..., port1); } ... } Later on, this now overwritten port1 gets assigned to ->portnum: dev->portnum = port1; However, since xhci_find_raw_port_number() isn't idempotent, the aforementioned commit causes a number of KASAN splats like the following: BUG: KASAN: slab-out-of-bounds in xhci_find_raw_port_number+0x98/0x170 at addr ffff8801d9311670 Read of size 8 by task kworker/2:1/87 [...] Workqueue: usb_hub_wq hub_event 0000000000000188 000000005814b877 ffff8800cba17588 ffffffff8191447e 0000000041b58ab3 ffffffff82a03209 ffffffff819143a2 ffffffff82a252f4 ffff8801d93115e0 0000000000000188 ffff8801d9311628 ffff8800cba17588 Call Trace: [] dump_stack+0xdc/0x15e [] ? _atomic_dec_and_lock+0xa2/0xa2 [] ? print_section+0x61/0xb0 [] print_trailer+0x179/0x2c0 [] object_err+0x34/0x40 [] kasan_report_error+0x2f8/0x8b0 [] ? __slab_alloc+0x5e/0x90 [] ? __lock_is_held+0x90/0x130 [] kasan_report+0x71/0xa0 [] ? kmem_cache_alloc_trace+0x212/0x560 [] ? xhci_find_raw_port_number+0x98/0x170 [] __asan_load8+0x64/0x70 [] xhci_find_raw_port_number+0x98/0x170 [] xhci_setup_addressable_virt_dev+0x235/0xa10 [] xhci_setup_device+0x3c1/0x1430 [] ? trace_hardirqs_on+0xd/0x10 [] ? xhci_setup_device+0x1430/0x1430 [] xhci_address_device+0x13/0x20 [] hub_port_init+0x55a/0x1550 [] hub_event+0xef5/0x24d0 [] ? hub_port_debounce+0x2f0/0x2f0 [] ? debug_object_deactivate+0x1be/0x270 [] ? print_rt_rq+0x53/0x2d0 [] ? trace_hardirqs_off+0xd/0x10 [] ? _raw_spin_unlock_irqrestore+0x5b/0x60 [] ? irq_domain_set_hwirq_and_chip+0x30/0xb0 [] ? debug_lockdep_rcu_enabled+0x39/0x40 [] ? __lock_is_held+0x90/0x130 [] process_one_work+0x567/0xec0 [...] Afterwards, xhci reports some functional errors: xhci_hcd 0000:00:14.0: ERROR: unexpected setup address command completion code 0x11. xhci_hcd 0000:00:14.0: ERROR: unexpected setup address command completion code 0x11. usb 4-3: device not accepting address 2, error -22 Fix this by not overwriting the port1 argument in usb_alloc_dev(), but storing the raw port number as required by OF in an additional variable, raw_port. Fixes: 69bec7259853 ("USB: core: let USB device know device node") Signed-off-by: Nicolai Stange Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman --- drivers/usb/core/usb.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c index ffa5cf13ffe1..dcb85e3cd5a7 100644 --- a/drivers/usb/core/usb.c +++ b/drivers/usb/core/usb.c @@ -424,6 +424,7 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent, struct usb_device *dev; struct usb_hcd *usb_hcd = bus_to_hcd(bus); unsigned root_hub = 0; + unsigned raw_port = port1; dev = kzalloc(sizeof(*dev), GFP_KERNEL); if (!dev) @@ -498,11 +499,11 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent, if (!parent->parent) { /* device under root hub's port */ - port1 = usb_hcd_find_raw_port_number(usb_hcd, + raw_port = usb_hcd_find_raw_port_number(usb_hcd, port1); } dev->dev.of_node = usb_of_get_child_node(parent->dev.of_node, - port1); + raw_port); /* hub driver sets up TT records */ } -- 2.7.3 --YiEDa0DAkWCtVeE4--