linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Neukum <oneukum@suse.de>
To: eli.billauer@gmail.com, gregkh@linuxfoundation.org,
	linux-usb@vger.kernel.org
Cc: hdegoede@redhat.com, stern@rowland.harvard.edu
Subject: Re: [PATCH] usb: core: Solve race condition in usb_kill_anchored_urbs
Date: Mon, 27 Jul 2020 12:14:00 +0200	[thread overview]
Message-ID: <1595844840.13408.17.camel@suse.de> (raw)
In-Reply-To: <20200727072225.25195-1-eli.billauer@gmail.com>

Am Montag, den 27.07.2020, 10:22 +0300 schrieb eli.billauer@gmail.com:
> From: Eli Billauer <eli.billauer@gmail.com>
> 
> usb_kill_anchored_urbs() is commonly used to cancel all URBs on an
> anchor just before releasing resources which the URBs rely on. By doing
> so, users of this function rely on that no completer callbacks will take
> place from any URB on the anchor after it returns.

Right, this is a use case that must work.

> However if this function is called in parallel with __usb_hcd_giveback_urb
> processing a URB on the anchor, the latter may call the completer
> callback after usb_kill_anchored_urbs() returns. This can lead to a
> kernel panic due to use after release of memory in interrupt context.
> 
> The race condition is that __usb_hcd_giveback_urb() first unanchors the URB
> and then makes the completer callback. Such URB is hence invisible to
> usb_kill_anchored_urbs(), allowing it to return before the completer has
> been called, since the anchor's urb_list is empty.

Well, the URB must be unachored because the callback may anchor the URB
again. What could we do? The refcount on the URB does not help, because
it guards only the URB itself.
It looks to me like I misdesigned the API a bit. What people really
need is an anchor that is not weighed by calling the callback.
Should I introduce such an API?

> This patch adds a call to usb_wait_anchor_empty_timeout() prior to
> returning. This function waits until urb_list is empty (it should
> already be), but more importantly, until @suspend_wakeups is zero.

That however is really a kludge we cannot have in usbcore.
I am afraid as is the patch should _not_ be applied.

	Regards
		Oliver


  parent reply	other threads:[~2020-07-27 10:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27  7:22 [PATCH] usb: core: Solve race condition in usb_kill_anchored_urbs eli.billauer
2020-07-27  9:21 ` Greg KH
2020-07-27 11:26   ` Eli Billauer
2020-07-27 10:14 ` Oliver Neukum [this message]
2020-07-27 11:27   ` Eli Billauer
2020-07-27 13:58     ` Oliver Neukum
2020-07-27 14:43       ` Alan Stern
2020-07-27 21:29         ` Oliver Neukum
2020-07-28  9:47           ` Eli Billauer
2020-07-28 13:42             ` Alan Stern
2020-07-28  9:44         ` Oliver Neukum
2020-07-28 13:39           ` Alan Stern

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=1595844840.13408.17.camel@suse.de \
    --to=oneukum@suse.de \
    --cc=eli.billauer@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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;
as well as URLs for NNTP newsgroup(s).