linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: eli.billauer@gmail.com
To: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org
Cc: hdegoede@redhat.com, stern@rowland.harvard.edu,
	Eli Billauer <eli.billauer@gmail.com>
Subject: [PATCH] usb: core: Solve race condition in usb_kill_anchored_urbs
Date: Mon, 27 Jul 2020 10:22:25 +0300	[thread overview]
Message-ID: <20200727072225.25195-1-eli.billauer@gmail.com> (raw)

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.

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.

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.

The latter condition resolves the race condition, since @suspend_wakeups
is incremented by __usb_hcd_giveback_urb() before unanchoring a URB and
decremented after completing it. @suspend_wakeups is hence an upper limit
of the number of unanchored but uncompleted URBs. By waiting for it to be
zero, the race condition is eliminated, in the same way that another
problem was solved for the same race condition in commit 6ec4147e7bdb
("usb-anchor: Delay usb_wait_anchor_empty_timeout wake up till completion
is done").

An arbitrary timeout of 1000 ms should cover any sane completer
callback. The wait condition may also fail if the anchor is populated
while usb_kill_anchored_urbs() is called. Both timeout scenarios are
alarmingly weird, hence a WARN() is issued.

Signed-off-by: Eli Billauer <eli.billauer@gmail.com>
---
 drivers/usb/core/urb.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
index da923ec17612..7fa23615199f 100644
--- a/drivers/usb/core/urb.c
+++ b/drivers/usb/core/urb.c
@@ -772,11 +772,12 @@ void usb_block_urb(struct urb *urb)
 EXPORT_SYMBOL_GPL(usb_block_urb);
 
 /**
- * usb_kill_anchored_urbs - cancel transfer requests en masse
+ * usb_kill_anchored_urbs -  kill all URBs associated with an anchor
  * @anchor: anchor the requests are bound to
  *
- * this allows all outstanding URBs to be killed starting
- * from the back of the queue
+ * This kills all outstanding URBs starting from the back of the queue,
+ * with guarantee that no completer callbacks will take place from the
+ * anchor after this function returns.
  *
  * This routine should not be called by a driver after its disconnect
  * method has returned.
@@ -784,6 +785,7 @@ EXPORT_SYMBOL_GPL(usb_block_urb);
 void usb_kill_anchored_urbs(struct usb_anchor *anchor)
 {
 	struct urb *victim;
+	int ret;
 
 	spin_lock_irq(&anchor->lock);
 	while (!list_empty(&anchor->urb_list)) {
@@ -798,6 +800,10 @@ void usb_kill_anchored_urbs(struct usb_anchor *anchor)
 		spin_lock_irq(&anchor->lock);
 	}
 	spin_unlock_irq(&anchor->lock);
+
+	ret = usb_wait_anchor_empty_timeout(anchor, 1000);
+
+	WARN(!ret, "Returning with non-empty anchor due to timeout");
 }
 EXPORT_SYMBOL_GPL(usb_kill_anchored_urbs);
 
-- 
2.17.1


             reply	other threads:[~2020-07-27  7:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27  7:22 eli.billauer [this message]
2020-07-27  9:21 ` [PATCH] usb: core: Solve race condition in usb_kill_anchored_urbs Greg KH
2020-07-27 11:26   ` Eli Billauer
2020-07-27 10:14 ` Oliver Neukum
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=20200727072225.25195-1-eli.billauer@gmail.com \
    --to=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).