Linux USB
 help / color / mirror / Atom feed
From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Ricardo Ribalda Delgado <ribalda@chromium.org>,
	Mathias Nyman <mathias.nyman@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	Stephen Boyd <swboyd@chromium.org>
Subject: Re: [PATCH] xhci: Do not create endpoint debugfs while holding the bandwidth mutex
Date: Thu, 1 Jun 2023 16:45:00 +0300	[thread overview]
Message-ID: <14d94fa1-1499-de1f-c924-9b823a606580@linux.intel.com> (raw)
In-Reply-To: <20230531-xhci-deadlock-v1-1-57780bff5124@chromium.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 <swboyd@chromium.org
> Fixes: 167657a1bb5f ("xhci: don't create endpoint debugfs entry before ring buffer is set.")
> Signed-off-by: Ricardo Ribalda Delgado <ribalda@chromium.org>
> ---
> 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


  parent reply	other threads:[~2023-06-01 14:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-31 12:40 [PATCH] xhci: Do not create endpoint debugfs while holding the bandwidth mutex Ricardo Ribalda Delgado
2023-05-31 13:10 ` Greg Kroah-Hartman
2023-06-01 13:45 ` Mathias Nyman [this message]
2023-06-01 16:05   ` Ricardo Ribalda
2023-06-12 14:30     ` Mathias Nyman
2023-06-17 12:09       ` Ricardo Ribalda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=14d94fa1-1499-de1f-c924-9b823a606580@linux.intel.com \
    --to=mathias.nyman@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=ribalda@chromium.org \
    --cc=swboyd@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox