From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DE580C7EE2A for ; Thu, 1 Jun 2023 14:13:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234022AbjFAONx (ORCPT ); Thu, 1 Jun 2023 10:13:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233955AbjFAONw (ORCPT ); Thu, 1 Jun 2023 10:13:52 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DFF07180; Thu, 1 Jun 2023 07:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1685628830; x=1717164830; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=Nq286GKnh90xOwApeBUtq++zLOYj3gW5k7/CVSmWRB0=; b=Vd7po3qG8HWyCVwhR1b3nmzO4reEH0g6jqPZVO3dcm5NCiGUqCFp3GzO zdI8B5aNI9vlult+sDa4G1vSlRi+C1A8MiZ7y+lApZjtzpnyx7LOTJ5eB ueAFJ7w4WuyZVmV7D19ngGikkPxb9i3+GalyIo3GTsQL4GgDHL2ihtzkn uGykKFZBbAV38cWE1TSZry8wRu9txcRprqyTjZwPmJf6K6NgxBEBcuCLO V9N3JbBDeMgt/rYxVszw6W+U9yqKpkLq+3USEDFFSXOerpsnlyPcaE6Qi c+uUycxDDWiEs8kf2vCGlRakJGEuqvZP8zNEoB8I1vqBooC0QWYapt1GJ w==; X-IronPort-AV: E=McAfee;i="6600,9927,10728"; a="421365624" X-IronPort-AV: E=Sophos;i="6.00,210,1681196400"; d="scan'208";a="421365624" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2023 06:43:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10728"; a="851698880" X-IronPort-AV: E=Sophos;i="6.00,210,1681196400"; d="scan'208";a="851698880" Received: from mattu-haswell.fi.intel.com (HELO [10.237.72.199]) ([10.237.72.199]) by fmsmga001.fm.intel.com with ESMTP; 01 Jun 2023 06:43:40 -0700 Message-ID: <14d94fa1-1499-de1f-c924-9b823a606580@linux.intel.com> Date: Thu, 1 Jun 2023 16:45:00 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.10.0 Content-Language: en-US To: Ricardo Ribalda Delgado , Mathias Nyman , Greg Kroah-Hartman Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Stephen Boyd References: <20230531-xhci-deadlock-v1-1-57780bff5124@chromium.org> From: Mathias Nyman Subject: Re: [PATCH] xhci: Do not create endpoint debugfs while holding the bandwidth mutex In-Reply-To: <20230531-xhci-deadlock-v1-1-57780bff5124@chromium.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org On 31.5.2023 15.40, Ricardo Ribalda Delgado wrote: > xhci_debugfs_create_endpoint needs to take the mm->mmap_sem, which is > not serialized with the hcd->bandwidth_mutex across the codebase. > > Without this patch a deadlock has been observed with the uvc driver at > the functions v4l2_mmap() and usb_set_interface(). > > Cc: Stephen Boyd Fixes: 167657a1bb5f ("xhci: don't create endpoint debugfs entry before ring buffer is set.") > Signed-off-by: Ricardo Ribalda Delgado > --- > I do not have a proper reproducer for this and I am not used to this > subsystem, so please take a careful look at this patch :). > > Thanks! Do you still have the lockdep output showing the deadlock? I'm not sure how calling xhci_debugfs_create_endpoint() from xhci_add_endpoint() instead of xhci_check_bandwidth() helps. Both are called with hcd->bandwidth_mutex held: usb_set_interface() mutex_lock(hcd->bandwidth_mutex); usb_hcd_alloc_bandwidth() hcd->driver->add_endpoint() -> xhci_add_endpoint() hcd->driver->check_bandwidth() -> xhci_check_bandwidth() mutex_unlock(hcd->bandwidth_mutex); Thanks Mathias