Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Alan Stern <email@example.com>
To: Krzysztof Kozlowski <firstname.lastname@example.org>
Cc: Felipe Balbi <email@example.com>,
Greg Kroah-Hartman <firstname.lastname@example.org>,
Pavel Skripkin <email@example.com>,
Thierry Escande <firstname.lastname@example.org>,
Andrey Konovalov <email@example.com>
Subject: Re: [syzbot] INFO: task hung in port100_probe
Date: Wed, 20 Oct 2021 18:05:03 -0400 [thread overview]
Message-ID: <20211020220503.GB1140001@rowland.harvard.edu> (raw)
On Wed, Oct 20, 2021 at 10:56:42PM +0200, Krzysztof Kozlowski wrote:
> Hi Alan, Felipe, Greg and others,
> This is an old issue reported by syzkaller for NFC port100 driver .
> There is something similar for pn533 .
> I was looking at it some time ago, took a break and now I am trying to
> fix it again. Without success.
> The issue is reproducible via USB gadget on QEMU, not on real HW. I
> looked and debugged the code and I think previously mentioned
> double-URB-submit is not the reason here. Or I miss how the USB works
> (which is quite probable...).
> 1. The port100 driver calls port100_send_cmd_sync() which eventually
> goes to port100_send_frame_async(). After it, it waits for "sync"
> 2. In port100_send_frame_async(), driver indeed first submits "out_urb"
> which quite fast is being processed by dummy_hcd with "no ep configured"
> and -EPROTO.
> 3. Then (or sometimes before -EPROTO response from (2) above) the
> port100_send_frame_async() submits "in_urb" via
> port100_submit_urb_for_ack() and waits for its completion. Completion of
> "in_urb" (or the "ack") in port100_recv_ack() would schedule work to
> complete the (1) above - the sync completion.
> 4. Usually, when reproducer works fine (does not trigger issue), the
> dummy_timer() from gadget responds with the same "no ep configured for
> urb" for this "in_urb" (3). This completes "in_urb", which eventually
> completes (1) and probe finishes with error. Error is expected, because
> it's random junk-gadget...
> The syzkaller reproducer fails if >1 of threads are running these usb
> gadgets. When this happens, no "in_urb" completion happens. No this
> "ack" port100_recv_ack().
> I added some debugs and simply dummy_hcd dummy_timer() is woken up on
> enqueuing in_urb and then is looping crazy on a previous URB (some older
> URB, coming from before port100 driver probe started). The dummy_timer()
> loop never reaches the second "in_urb" to process it, I think.
Is there any way you can track down what's happening in that crazy loop?
That is, what driver was responsible for the previous URB?
We have seen this sort of thing before, where a driver submits an URB
for a gadget which has disconnected. The URB fails with -EPROTO status
but the URB's completion handler does an automatic resubmit. That can
lead to a very tight loop with dummy-hcd, and it could easily prevent
some other important processing from occurring. The simple solution is
to prevent the driver from resubmitting when the completion status is
> The pn533 NFC driver has similar design, but I have now really doubts it
> is a NFC driver issue. Instead an issue in dummy gadget HCD is somehow
> triggered by the reproducer.
> Reproduction - just follow  or . Eventually I slightly tweaked the
> code and put here:
> $ make
> $ sudo ./port100_probe
>  https://syzkaller.appspot.com/bug?extid=abd2e0dafb481b621869
>  https://syzkaller.appspot.com/bug?extid=1dc8b460d6d48d7ef9ca
> Best regards,
next prev parent reply other threads:[~2021-10-20 22:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-22 15:43 syzbot
2021-06-22 16:07 ` Pavel Skripkin
2021-06-22 16:21 ` syzbot
2021-07-22 14:20 ` Krzysztof Kozlowski
2021-07-22 14:23 ` Krzysztof Kozlowski
2021-07-22 14:47 ` Alan Stern
2021-07-23 9:05 ` Krzysztof Kozlowski
2021-07-23 13:07 ` Alan Stern
2021-10-20 20:56 ` Krzysztof Kozlowski
2021-10-20 22:05 ` Alan Stern [this message]
2021-10-25 14:57 ` Krzysztof Kozlowski
2021-10-25 16:22 ` Alan Stern
2021-10-25 17:13 ` Krzysztof Kozlowski
2021-10-25 18:54 ` Alan Stern
2022-03-09 19:33 ` Pavel Skripkin
2022-03-09 19:56 ` syzbot
[not found] <firstname.lastname@example.org>
2022-03-10 14:22 ` syzbot
[not found] ` <email@example.com>
2022-03-11 19:17 ` Pavel Skripkin
2022-03-11 19:18 ` syzbot
2022-03-11 19:19 ` Pavel Skripkin
2022-03-11 19:32 ` syzbot
[not found] ` <firstname.lastname@example.org>
2022-03-12 10:36 ` Pavel Skripkin
[not found] ` <email@example.com>
2022-03-12 12:44 ` Pavel Skripkin
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [syzbot] INFO: task hung in port100_probe' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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).