From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753047AbcBJQoU (ORCPT ); Wed, 10 Feb 2016 11:44:20 -0500 Received: from mga02.intel.com ([134.134.136.20]:59747 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752083AbcBJQoS (ORCPT ); Wed, 10 Feb 2016 11:44:18 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,426,1449561600"; d="scan'208";a="909372963" Message-ID: <56BB6A3E.4020006@linux.intel.com> Date: Wed, 10 Feb 2016 18:50:06 +0200 From: Mathias Nyman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Chris Bainbridge , Alan Stern CC: johan@kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] usb: host: xhci: Replace bus lock with host controller lock References: <20160204220621.GA5612@localhost> <20160205151407.GA5257@localhost> In-Reply-To: <20160205151407.GA5257@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05.02.2016 17:14, Chris Bainbridge wrote: > Running task list at fail point: ... > Some of the functions appear to be inlined, the exact call chain is: > > hub_port_init > usb_get_device_descriptor > usb_get_descriptor > usb_control_msg > usb_internal_control_msg > usb_start_wait_urb > usb_submit_urb / wait_for_completion_timeout / usb_kill_urb > > hub_port_init > hub_set_address > xhci_address_device > xhci_setup_device > hub_port_reset() will end up moving the corresponding xhci device slot to default state. As hub_port_reset() is called several times in hub_port_init() It sounds reasonable that we could end up with two threads having their xhci device slots in default state at the same time, which according to xhci 4.5.3 specs still is a big no no. So both threads fail at their next task after this. One fails to read the descriptor, and the other fails addressing the device. Nice catch btw. > So xhci_setup_device is entered while there is an outstanding URB on the > other bus. Unless anyone can think of a better way to fix this I'll make > the requested changes and resend my patch. > For what it's wort I think that this suggested controller mutex sounds like a good idea. Should work for xhci at least. -Mathias