mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Oliver Neukum <oneukum@suse.com>
To: syzbot <syzbot+f342ea16c9d06d80b585@syzkaller.appspotmail.com>,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	linux-usb@vger.kernel.org, stern@rowland.harvard.edu,
	sylv@sylv.io, syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [usb?] INFO: task hung in usb_port_suspend
Date: Mon, 21 Oct 2024 10:04:52 +0200	[thread overview]
Message-ID: <0abd3cbd-0e8a-43b2-8cb0-6556297aa7c9@suse.com> (raw)
In-Reply-To: <67153205.050a0220.1e4b4d.0048.GAE@google.com>

On 20.10.24 18:38, syzbot wrote:
  
> INFO: task kworker/0:0:8 blocked for more than 143 seconds.
>        Not tainted 6.12.0-rc3-syzkaller-00051-g07b887f8236e #0
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> task:kworker/0:0     state:D stack:24544 pid:8     tgid:8     ppid:2      flags:0x00004000
> Workqueue: pm pm_runtime_work
> Call Trace:
>   <TASK>
>   context_switch kernel/sched/core.c:5322 [inline]
>   __schedule+0x105f/0x34b0 kernel/sched/core.c:6682
>   __schedule_loop kernel/sched/core.c:6759 [inline]
>   schedule+0xe7/0x350 kernel/sched/core.c:6774

And this sleeps forever. This must not happen.
>   usb_kill_urb.part.0+0x1ca/0x250 drivers/usb/core/urb.c:713
>   usb_kill_urb+0x83/0xa0 drivers/usb/core/urb.c:702

We are changing our mind, presumably due to a timeout
>   usb_start_wait_urb+0x255/0x4c0 drivers/usb/core/message.c:65

We are sending a control message, presumably to enable
remote wakeup
>   usb_internal_control_msg drivers/usb/core/message.c:103 [inline]
>   usb_control_msg+0x327/0x4b0 drivers/usb/core/message.c:154
>   usb_enable_remote_wakeup drivers/usb/core/hub.c:3365 [inline]
>   usb_port_suspend+0x339/0xf10 drivers/usb/core/hub.c:3472

Suspending ...
>   usb_generic_driver_suspend+0xeb/0x1d0 drivers/usb/core/generic.c:302
>   usb_suspend_device drivers/usb/core/driver.c:1272 [inline]
>   usb_suspend_both+0x66d/0x9c0 drivers/usb/core/driver.c:1443
>   usb_runtime_suspend+0x49/0x180 drivers/usb/core/driver.c:1968

This very much looks like the HC driver used to run these tests
can hand in unlink. If that happens there is nothing usbcore
or a driver can do.
As this is now reproducible I would suggest a bisection. Brute force,
but I see no good alternative.

Syzbot is an important tool and if the HC driver it uses is unreliable,
the whole thing becomes unreliable and that is most undesirable.

	Regards
		Oliver



  reply	other threads:[~2024-10-21  8:04 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-11 13:08 syzbot
2024-10-11 14:08 ` Alan Stern
2024-10-11 14:35   ` syzbot
2024-10-11 14:55     ` Alan Stern
2024-10-11 15:00       ` syzbot
2024-10-11 15:17         ` Alan Stern
2024-10-11 15:45           ` syzbot
2024-10-12  0:48             ` Alan Stern
2024-10-12  1:14               ` syzbot
2024-10-13  1:09                 ` Alan Stern
2024-10-13  2:10                   ` syzbot
2024-10-13  2:43                     ` Alan Stern
2024-10-13  3:05                       ` syzbot
2024-10-13 14:30                         ` Alan Stern
2024-10-13 15:02                           ` syzbot
2024-10-13 15:45                             ` Alan Stern
2024-10-13 16:14                               ` syzbot
2024-10-13 18:02                                 ` Alan Stern
2024-10-13 18:38                                   ` syzbot
2024-10-13 19:24                                     ` Alan Stern
2024-10-13 20:34                                       ` syzbot
2024-10-14  1:24 ` [syzbot] " syzbot
2024-10-20 16:38 ` syzbot
2024-10-21  8:04   ` Oliver Neukum [this message]
2024-10-21 13:37     ` Alan Stern
2024-10-22 11:42     ` Hillf Danton
2024-10-22 10:46 ` Hillf Danton
2024-10-22 11:29   ` syzbot
     [not found] <b9bea8cd-effc-484f-ac46-1644093adffe@rowland.harvard.edu>
2024-10-14  1:58 ` syzbot
2024-10-14 16:14   ` Alan Stern
2024-10-14 17:20     ` syzbot
2024-10-14 18:21       ` Alan Stern
2024-10-14 18:42         ` syzbot
2024-10-14 22:38           ` Alan Stern
2024-10-14 22:57             ` syzbot
2024-10-15  0:43               ` Alan Stern
2024-10-15  0:45                 ` syzbot
2024-10-15  1:31                   ` Alan Stern
2024-10-15 14:22           ` Alan Stern
2024-10-15 14:54             ` syzbot
2024-10-15 19:23               ` Alan Stern
2024-10-15 19:54                 ` syzbot
2024-10-16  0:54                   ` Alan Stern
2024-10-16  1:54                     ` syzbot
2024-10-16  2:11                       ` Alan Stern
2024-10-16  2:34                         ` syzbot
2024-10-16 14:40                           ` Alan Stern
2024-10-16 15:02                             ` syzbot

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=0abd3cbd-0e8a-43b2-8cb0-6556297aa7c9@suse.com \
    --to=oneukum@suse.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=sylv@sylv.io \
    --cc=syzbot+f342ea16c9d06d80b585@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®