All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: syzbot <syzbot+d919b0f29d7b5a4994b9@syzkaller.appspotmail.com>
Cc: andreyknvl@google.com, <gregkh@linuxfoundation.org>,
	<gustavo@embeddedor.com>, <linux-kernel@vger.kernel.org>,
	<linux-usb@vger.kernel.org>, <syzkaller-bugs@googlegroups.com>
Subject: Re: INFO: task hung in usb_kill_urb
Date: Tue, 16 Apr 2019 17:14:38 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1904161707210.1605-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <000000000000fb61d40586aa6a1e@google.com>

On Tue, 16 Apr 2019, syzbot wrote:

> Hello,
> 
> syzbot has tested the proposed patch and the reproducer did not trigger  
> crash:

Slight fixup to the patch.  Unsupported speeds aren't necessarily 
bogus, and what matters is the actual speed rather than the max_speed.
Also, we want to be able to give back unlinked URBs even after a 
frame's total bandwidth has been exhausted.

Alan Stern

#syz test: https://github.com/google/kasan.git usb-fuzzer

--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -979,8 +979,18 @@ static int dummy_udc_start(struct usb_ga
 	struct dummy_hcd	*dum_hcd = gadget_to_dummy_hcd(g);
 	struct dummy		*dum = dum_hcd->dum;
 
-	if (driver->max_speed == USB_SPEED_UNKNOWN)
+	switch (g->speed) {
+	/* All the speeds we support */
+	case USB_SPEED_LOW:
+	case USB_SPEED_FULL:
+	case USB_SPEED_HIGH:
+	case USB_SPEED_SUPER:
+		break;
+	default:
+		dev_err(dummy_dev(dum_hcd), "Unsupported driver max speed %d\n",
+				driver->max_speed);
 		return -EINVAL;
+	}
 
 	/*
 	 * SLAVE side init ... the layer above hardware, which
@@ -1784,7 +1794,7 @@ static void dummy_timer(struct timer_lis
 		/* Bus speed is 500000 bytes/ms, so use a little less */
 		total = 490000;
 		break;
-	default:
+	default:	/* Can't happen */
 		dev_err(dummy_dev(dum_hcd), "bogus device speed\n");
 		return;
 	}
@@ -1828,7 +1838,7 @@ restart:
 
 		/* Used up this frame's bandwidth? */
 		if (total <= 0)
-			break;
+			continue;
 
 		/* find the gadget's ep for this request (if configured) */
 		address = usb_pipeendpoint (urb->pipe);


WARNING: multiple messages have this Message-ID (diff)
From: Alan Stern <stern@rowland.harvard.edu>
To: syzbot <syzbot+d919b0f29d7b5a4994b9@syzkaller.appspotmail.com>
Cc: andreyknvl@google.com, gregkh@linuxfoundation.org,
	gustavo@embeddedor.com, linux-kernel@vger.kernel.org,
	linux-usb@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: INFO: task hung in usb_kill_urb
Date: Tue, 16 Apr 2019 17:14:38 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1904161707210.1605-100000@iolanthe.rowland.org> (raw)

On Tue, 16 Apr 2019, syzbot wrote:

> Hello,
> 
> syzbot has tested the proposed patch and the reproducer did not trigger  
> crash:

Slight fixup to the patch.  Unsupported speeds aren't necessarily 
bogus, and what matters is the actual speed rather than the max_speed.
Also, we want to be able to give back unlinked URBs even after a 
frame's total bandwidth has been exhausted.

Alan Stern

#syz test: https://github.com/google/kasan.git usb-fuzzer

--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -979,8 +979,18 @@ static int dummy_udc_start(struct usb_ga
 	struct dummy_hcd	*dum_hcd = gadget_to_dummy_hcd(g);
 	struct dummy		*dum = dum_hcd->dum;
 
-	if (driver->max_speed == USB_SPEED_UNKNOWN)
+	switch (g->speed) {
+	/* All the speeds we support */
+	case USB_SPEED_LOW:
+	case USB_SPEED_FULL:
+	case USB_SPEED_HIGH:
+	case USB_SPEED_SUPER:
+		break;
+	default:
+		dev_err(dummy_dev(dum_hcd), "Unsupported driver max speed %d\n",
+				driver->max_speed);
 		return -EINVAL;
+	}
 
 	/*
 	 * SLAVE side init ... the layer above hardware, which
@@ -1784,7 +1794,7 @@ static void dummy_timer(struct timer_lis
 		/* Bus speed is 500000 bytes/ms, so use a little less */
 		total = 490000;
 		break;
-	default:
+	default:	/* Can't happen */
 		dev_err(dummy_dev(dum_hcd), "bogus device speed\n");
 		return;
 	}
@@ -1828,7 +1838,7 @@ restart:
 
 		/* Used up this frame's bandwidth? */
 		if (total <= 0)
-			break;
+			continue;
 
 		/* find the gadget's ep for this request (if configured) */
 		address = usb_pipeendpoint (urb->pipe);

  reply	other threads:[~2019-04-16 21:14 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAAeHK+wDEOpkuh0+OmPra3Yu8ri-8As82CyZ-1KyYC62AJkj1Q@mail.gmail.com>
2019-04-16 15:44 ` INFO: task hung in usb_kill_urb Alan Stern
2019-04-16 15:44   ` Alan Stern
2019-04-16 16:19   ` syzbot
2019-04-16 16:19     ` syzbot
2019-04-16 18:25     ` Alan Stern
2019-04-16 18:25       ` Alan Stern
2019-04-16 19:03       ` syzbot
2019-04-16 19:03         ` syzbot
2019-04-16 21:14         ` Alan Stern [this message]
2019-04-16 21:14           ` Alan Stern
2019-04-16 21:53           ` syzbot
2019-04-16 21:53             ` syzbot
2019-04-17 19:09             ` Alan Stern
2019-04-17 19:09               ` Alan Stern
2019-04-17 19:56               ` syzbot
2019-04-17 19:56                 ` syzbot
2019-04-18 12:21               ` Andrey Konovalov
2019-04-18 12:21                 ` Andrey Konovalov
2019-04-17 11:16       ` Andrey Konovalov
2019-04-17 11:16         ` Andrey Konovalov
2019-04-19 18:36         ` UDC hardware for fuzzing [was: Re: INFO: task hung in usb_kill_urb] Alan Stern
2019-04-19 18:36           ` INFO: task hung in usb_kill_urb Alan Stern
2019-04-23 12:44           ` UDC hardware for fuzzing [was: Re: INFO: task hung in usb_kill_urb] Andrey Konovalov
2019-04-23 12:44             ` INFO: task hung in usb_kill_urb Andrey Konovalov
2019-04-18 17:12 USB: dummy-hcd: Fix failure to give back unlinked URBs Alan Stern
2019-04-18 17:12 ` [PATCH] " Alan Stern
  -- strict thread matches above, loose matches on Subject: below --
2019-04-12 11:46 INFO: task hung in usb_kill_urb syzbot
2019-04-12 19:46 ` Alan Stern
2019-04-15 17:48   ` Andrey Konovalov
2019-04-15 18:06     ` Alan Stern
2019-04-15 18:39     ` Gustavo A. R. Silva
2019-04-15 19:00       ` Greg Kroah-Hartman
2019-04-15 19:35         ` Andrey Konovalov

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=Pine.LNX.4.44L0.1904161707210.1605-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=andreyknvl@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gustavo@embeddedor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=syzbot+d919b0f29d7b5a4994b9@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.