[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0abd3cbd-0e8a-43b2-8cb0-6556297aa7c9@suse.com>
Date: Mon, 21 Oct 2024 10:04:52 +0200
From: Oliver Neukum <oneukum@...e.com>
To: syzbot <syzbot+f342ea16c9d06d80b585@...kaller.appspotmail.com>,
gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
linux-usb@...r.kernel.org, stern@...land.harvard.edu, sylv@...v.io,
syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [usb?] INFO: task hung in usb_port_suspend
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
Powered by blists - more mailing lists