Re: BUG: unable to handle kernel paging request in corrupted (2)
On Fri, Jul 19, 2019 at 1:56 PM syzbot
wrote:
>
> syzbot has bisected this bug to:
>
> commit 9343ac87f2a4e09bf6e27b5f31e72e9e3a82abff
> Author: Dave Stevenson
> Date: Mon Jun 25 14:07:15 2018 +
>
> net: lan78xx: Use s/w csum check on VLANs without tag stripping
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=102feb8460
> start commit: 49d05fe2 ipv6: rt6_check should return NULL if 'from' is N..
> git tree: net
> final crash:https://syzkaller.appspot.com/x/report.txt?x=122feb8460
> console output: https://syzkaller.appspot.com/x/log.txt?x=142feb8460
> kernel config: https://syzkaller.appspot.com/x/.config?x=87305c3ca9c25c70
> dashboard link: https://syzkaller.appspot.com/bug?extid=08b7a2c58acdfa12c82d
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=143a78f460
>
> Reported-by: syzbot+08b7a2c58acdfa12c...@syzkaller.appspotmail.com
> Fixes: 9343ac87f2a4 ("net: lan78xx: Use s/w csum check on VLANs without tag
> stripping")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>From the repro it looks like the same bpf stack overflow bug. +John
We need to dup them onto some canonical report for this bug, or this
becomes unmanageable.
#syz dup: kernel panic: corrupted stack end in dput
Re: [PATCH v5 2/6] usb: gadget: u_serial: reimplement console support
On Tue, Jul 23, 2019 at 10:18:15AM +0800, Baolin Wang wrote:
> Hi Michal,
>
> On Mon, 22 Jul 2019 at 23:26, Michał Mirosław wrote:
> >
> > Rewrite console support to fix a few shortcomings of the old code
> > preventing its use with multiple ports. This removes some duplicated
> > code and replaces a custom kthread with simpler workqueue item.
>
> Could you elaborate on why changing kthread to a workqueue? The
> purpose of using kthread here is considering that the kthead has a
> better scheduler response than pooled kworker.
...which is not that relevant there. Current kthead implementation
is buggy, see this series for what needs to be done to fix it:
https://marc.info/?l=linux-usb&m=156305214227371&w=2
and as Michał's fix is superior to fixing kthread I'm voting for his
solution. Only one of my patches is still needed and I'll resend
once this fix hits -next.
> >
> > Only port ttyGS0 gets to be a console for now.
> >
> > Signed-off-by: Michał Mirosław
> > Reviewed-by: Greg Kroah-Hartman
> > Tested-by: Ladislav Michl
> >
> > ---
> > v5: no changes
> > v4: cosmetic change to __gs_console_push()
> > v3: no changes
> > v2: no changes
> >
> > ---
> > drivers/usb/gadget/function/u_serial.c | 351 -
> > 1 file changed, 164 insertions(+), 187 deletions(-)
> >
> > diff --git a/drivers/usb/gadget/function/u_serial.c
> > b/drivers/usb/gadget/function/u_serial.c
> > index bb1e2e1d0076..94f6999e8262 100644
> > --- a/drivers/usb/gadget/function/u_serial.c
> > +++ b/drivers/usb/gadget/function/u_serial.c
> > @@ -82,14 +82,12 @@
> > #define GS_CONSOLE_BUF_SIZE8192
> >
> > /* console info */
> > -struct gscons_info {
> > - struct gs_port *port;
> > - struct task_struct *console_thread;
> > - struct kfifocon_buf;
> > - /* protect the buf and busy flag */
> > - spinlock_t con_lock;
> > - int req_busy;
> > - struct usb_request *console_req;
> > +struct gs_console {
> > + struct console console;
> > + struct work_struct work;
> > + spinlock_t lock;
> > + struct usb_request *req;
> > + struct kfifobuf;
> > };
> >
> > /*
> > @@ -101,6 +99,9 @@ struct gs_port {
> > spinlock_t port_lock; /* guard port_* access */
> >
> > struct gserial *port_usb;
> > +#ifdef CONFIG_U_SERIAL_CONSOLE
> > + struct gs_console *console;
> > +#endif
> >
> > boolopenclose; /* open/close in progress */
> > u8 port_num;
> > @@ -889,36 +890,9 @@ static struct tty_driver *gs_tty_driver;
> >
> > #ifdef CONFIG_U_SERIAL_CONSOLE
> >
> > -static struct gscons_info gscons_info;
> > -static struct console gserial_cons;
> > -
> > -static struct usb_request *gs_request_new(struct usb_ep *ep)
> > +static void gs_console_complete_out(struct usb_ep *ep, struct usb_request
> > *req)
> > {
> > - struct usb_request *req = usb_ep_alloc_request(ep, GFP_ATOMIC);
> > - if (!req)
> > - return NULL;
> > -
> > - req->buf = kmalloc(ep->maxpacket, GFP_ATOMIC);
> > - if (!req->buf) {
> > - usb_ep_free_request(ep, req);
> > - return NULL;
> > - }
> > -
> > - return req;
> > -}
> > -
> > -static void gs_request_free(struct usb_request *req, struct usb_ep *ep)
> > -{
> > - if (!req)
> > - return;
> > -
> > - kfree(req->buf);
> > - usb_ep_free_request(ep, req);
> > -}
> > -
> > -static void gs_complete_out(struct usb_ep *ep, struct usb_request *req)
> > -{
> > - struct gscons_info *info = &gscons_info;
> > + struct gs_console *cons = req->context;
> >
> > switch (req->status) {
> > default:
> > @@ -927,12 +901,12 @@ static void gs_complete_out(struct usb_ep *ep, struct
> > usb_request *req)
> > /* fall through */
> > case 0:
> > /* normal completion */
> > - spin_lock(&info->con_lock);
> > - info->req_busy = 0;
> > - spin_unlock(&info->con_lock);
> > -
> > - wake_up_process(info->console_thread);
> > + spin_lock(&cons->lock);
> > + req->length = 0;
> > + schedule_work(&cons->work);
> > + spin_unlock(&cons->lock);
> > break;
> > + case -ECONNRESET:
> > case -ESHUTDOWN:
> > /* disconnect */
> > pr_vdebug("%s: %s shutdown\n", __func__, ep->name);
> > @@ -940,190 +914,190 @@ static void gs_complete_out(struct usb_ep *ep,
> > struct usb_request *req)
> > }
> > }
> >
> > -static int gs_console_connect(int port_num)
> > +static void __gs_console_push(struct gs_console *cons)
> > {
> > - struct gscons_info *info = &gscons_info;
> > - struct gs_port *port;
> > + struct usb_r
Re: [PATCH v5 2/6] usb: gadget: u_serial: reimplement console support
On Tue, Jul 23, 2019 at 10:18:15AM +0800, Baolin Wang wrote: > Hi Michal, > > On Mon, 22 Jul 2019 at 23:26, Michał Mirosław wrote: > > > > Rewrite console support to fix a few shortcomings of the old code > > preventing its use with multiple ports. This removes some duplicated > > code and replaces a custom kthread with simpler workqueue item. > Could you elaborate on why changing kthread to a workqueue? The > purpose of using kthread here is considering that the kthead has a > better scheduler response than pooled kworker. Mainly locking problems and single-instance design. The kthread looked like it's reimplementing workqueue mechanics. If the scheduling latency turns out important, the workqueue used can be changed to dedicated one or one with higher priority. Best Regards, Michał Mirosław
High-Impact: xhci_hid - "Not enough bandwidth for new device state"
Dear Linux-USB, https://bugzilla.redhat.com/show_bug.cgi?id=1411604 - This bug is around since 5 years. - Severity: High - "It's not Fedora specific, it's linux in general" There are 671 results in Google for 'USB "Not enough bandwidth for new device state"'. Why does nobody take this on? I offer to send you or whoever a Logitech C922 WebCam if it accelerates the process :-) The bug basically keeps people from using a USB 3.0 WebCam in parallel to some virtual machine Audio. This means it will affect any "professional" users who need to do GoToMeeting or WebEx together with running a Windows VM. I've posted in AskUbuntu.com: https://askubuntu.com/questions/1149160/what-to-do-with-usb-webcam-not-enough-bandwidth-for-new-device-state-issue Thanks Frank Frank Bergmann Dipl.-Ing., MBA Founder ]project-open[ Tel: +34 932 202 088 (Spain) Tel: +1 415 429 5995 (USA) Cell: +34 609 953 751 Fax: +34 932 890 729 mailto:frank.bergm...@project-open.com http://www.project-open.com http://www.twitter.com/projop http://www.facebook.com/projectopen.org http://www.linkedin.com/in/fraber http://www.xing.com/profile/Frank_Bergmann23
Re: High-Impact: xhci_hid - "Not enough bandwidth for new device state"
On Tue, Jul 23, 2019 at 02:31:18PM +0200, Frank Bergmann wrote: > Dear Linux-USB, > > > https://bugzilla.redhat.com/show_bug.cgi?id=1411604 > > - This bug is around since 5 years. > > - Severity: High > > - "It's not Fedora specific, it's linux in general" > > > There are 671 results in Google for 'USB "Not enough bandwidth for new > device state"'. Why does nobody take this on? Because there's not much to be done here. You are trying to add a device to the USB bus that is asking for more bandwidth than the bus currently can provide. So we fail the device addition. What are we supposed to do instead? > > > I offer to send you or whoever a Logitech C922 WebCam if it accelerates the > process :-) > > > The bug basically keeps people from using a USB 3.0 WebCam in parallel to > some virtual machine Audio. This means it will affect any "professional" > users who need to do GoToMeeting or WebEx together with running a Windows > VM. Why do you say that? Many people have that configuration working just fine. Personally I have a ton of USB devices all plugged into one USB 3 port running at the same time (webcam, audio devices, keyboard, mouse) and video conferences work just fine with that. Try plugging the device into a separate USB root hub and you should be fine, as we can't do the impossible here (get extra bandwidth than what is present on the system). thanks, greg k-h
KASAN: use-after-free Read in hidraw_ioctl
Hello, syzbot found the following crash on: HEAD commit:6a3599ce usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=107e726460 kernel config: https://syzkaller.appspot.com/x/.config?x=700ca426ab83faae dashboard link: https://syzkaller.appspot.com/bug?extid=ded1794a717e3b235226 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13b98b4c60 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1619b07c60 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+ded1794a717e3b235...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in hidraw_ioctl+0x609/0xaf0 /drivers/hid/hidraw.c:380 Read of size 4 at addr 8881d549a118 by task syz-executor073/2445 CPU: 0 PID: 2445 Comm: syz-executor073 Not tainted 5.2.0-rc6+ #15 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack /lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e /lib/dump_stack.c:113 print_address_description+0x67/0x231 /mm/kasan/report.c:188 __kasan_report.cold+0x1a/0x32 /mm/kasan/report.c:317 kasan_report+0xe/0x20 /mm/kasan/common.c:614 hidraw_ioctl+0x609/0xaf0 /drivers/hid/hidraw.c:380 vfs_ioctl /fs/ioctl.c:46 [inline] file_ioctl /fs/ioctl.c:509 [inline] do_vfs_ioctl+0xcda/0x12e0 /fs/ioctl.c:696 ksys_ioctl+0x9b/0xc0 /fs/ioctl.c:713 __do_sys_ioctl /fs/ioctl.c:720 [inline] __se_sys_ioctl /fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x6f/0xb0 /fs/ioctl.c:718 do_syscall_64+0xb7/0x560 /arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x451fd9 Code: e8 ec e7 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b cb fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f3144bd5ce8 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 006e3c88 RCX: 00451fd9 RDX: 200015c0 RSI: 80044801 RDI: 0005 RBP: 006e3c80 R08: R09: R10: R11: 0246 R12: 006e3c8c R13: 7ffc64ba492f R14: 7f3144bd69c0 R15: 0002 Allocated by task 5: save_stack+0x1b/0x80 /mm/kasan/common.c:71 set_track /mm/kasan/common.c:79 [inline] __kasan_kmalloc /mm/kasan/common.c:489 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 /mm/kasan/common.c:462 kmalloc /./include/linux/slab.h:547 [inline] kzalloc /./include/linux/slab.h:742 [inline] hid_allocate_device+0x3e/0x480 /drivers/hid/hid-core.c:2389 usbhid_probe+0x23e/0xfa0 /drivers/hid/usbhid/hid-core.c:1321 usb_probe_interface+0x305/0x7a0 /drivers/usb/core/driver.c:361 really_probe+0x281/0x660 /drivers/base/dd.c:509 driver_probe_device+0x104/0x210 /drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 /drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 /drivers/base/bus.c:454 __device_attach+0x217/0x360 /drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 /drivers/base/bus.c:514 device_add+0xae6/0x16f0 /drivers/base/core.c:2111 usb_set_configuration+0xdf6/0x1670 /drivers/usb/core/message.c:2023 generic_probe+0x9d/0xd5 /drivers/usb/core/generic.c:210 usb_probe_device+0x99/0x100 /drivers/usb/core/driver.c:266 really_probe+0x281/0x660 /drivers/base/dd.c:509 driver_probe_device+0x104/0x210 /drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 /drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 /drivers/base/bus.c:454 __device_attach+0x217/0x360 /drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 /drivers/base/bus.c:514 device_add+0xae6/0x16f0 /drivers/base/core.c:2111 usb_new_device.cold+0x6a4/0xe61 /drivers/usb/core/hub.c:2536 hub_port_connect /drivers/usb/core/hub.c:5098 [inline] hub_port_connect_change /drivers/usb/core/hub.c:5213 [inline] port_event /drivers/usb/core/hub.c:5359 [inline] hub_event+0x1abd/0x3550 /drivers/usb/core/hub.c:5441 process_one_work+0x905/0x1570 /kernel/workqueue.c:2269 worker_thread+0x96/0xe20 /kernel/workqueue.c:2415 kthread+0x30b/0x410 /kernel/kthread.c:255 ret_from_fork+0x24/0x30 /arch/x86/entry/entry_64.S:352 Freed by task 1781: save_stack+0x1b/0x80 /mm/kasan/common.c:71 set_track /mm/kasan/common.c:79 [inline] __kasan_slab_free+0x130/0x180 /mm/kasan/common.c:451 slab_free_hook /mm/slub.c:1421 [inline] slab_free_freelist_hook /mm/slub.c:1448 [inline] slab_free /mm/slub.c:2994 [inline] kfree+0xd7/0x280 /mm/slub.c:3949 device_release+0x71/0x200 /drivers/base/core.c:1064 kobject_cleanup /lib/kobject.c:691 [inline] kobject_release /lib/kobject.c:720 [inline] kref_put /./include/linux/kref.h:65 [inline] kobject_put+0x171/0x280 /lib/kobject.c:737 put_device+0x1b/0x30 /drivers/base/core.c:2210 usbhid_disconnect+0x90/0xd
WARNING in usbvision_write_reg/usb_submit_urb
Hello, syzbot found the following crash on: HEAD commit:6a3599ce usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=17daca6460 kernel config: https://syzkaller.appspot.com/x/.config?x=700ca426ab83faae dashboard link: https://syzkaller.appspot.com/bug?extid=1fe821ea9f66c0df9cbf compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=113dda4460 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=174d46f460 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+1fe821ea9f66c0df9...@syzkaller.appspotmail.com usb 1-1: config 0 interface 237 altsetting 0 endpoint 0x83 has an invalid bInterval 0, changing to 7 usb 1-1: New USB device found, idVendor=0573, idProduct=4d21, bcdDevice=83.91 usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 1-1: config 0 descriptor?? usbvision_probe: Hauppauge WinTV USB Pro (PAL B/G) found [ cut here ] usb 1-1: BOGUS urb xfer, pipe 2 != type 1 WARNING: CPU: 0 PID: 12 at drivers/usb/core/urb.c:477 usb_submit_urb+0x1188/0x13b0 /drivers/usb/core/urb.c:477 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.2.0-rc6+ #15 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack /lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e /lib/dump_stack.c:113 panic+0x292/0x6c9 /kernel/panic.c:219 __warn.cold+0x20/0x4b /kernel/panic.c:576 report_bug+0x262/0x2a0 /lib/bug.c:186 fixup_bug /arch/x86/kernel/traps.c:179 [inline] fixup_bug /arch/x86/kernel/traps.c:174 [inline] do_error_trap+0x12b/0x1e0 /arch/x86/kernel/traps.c:272 do_invalid_op+0x32/0x40 /arch/x86/kernel/traps.c:291 invalid_op+0x14/0x20 /arch/x86/entry/entry_64.S:986 RIP: 0010:usb_submit_urb+0x1188/0x13b0 /drivers/usb/core/urb.c:477 Code: 4d 85 ed 74 2c e8 f8 d3 f4 fd 4c 89 f7 e8 a0 51 1c ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 00 0e f7 85 e8 83 98 ca fd <0f> 0b e9 20 f4 ff ff e8 cc d3 f4 fd 4c 89 f2 48 b8 00 00 00 00 00 RSP: 0018:8881d9e0f030 EFLAGS: 00010282 RAX: RBX: 0001 RCX: RDX: RSI: 8127ef3d RDI: ed103b3c1df8 RBP: 8881d946d900 R08: 8881d9df9800 R09: ed103b645d30 R10: ed103b645d2f R11: 8881db22e97f R12: 0002 R13: 8881ce015c90 R14: 8881d08bd5a0 R15: 8881d946d700 usb_start_wait_urb+0x108/0x2b0 /drivers/usb/core/message.c:57 usb_internal_control_msg /drivers/usb/core/message.c:101 [inline] usb_control_msg+0x31c/0x4a0 /drivers/usb/core/message.c:152 usbvision_write_reg+0x175/0x1f0 /drivers/media/usb/usbvision/usbvision-core.c:1383 usbvision_audio_off+0x1e/0xc0 /drivers/media/usb/usbvision/usbvision-core.c:2183 usbvision_configure_video /drivers/media/usb/usbvision/usbvision-video.c:1393 [inline] usbvision_probe.cold+0x120d/0x1d69 /drivers/media/usb/usbvision/usbvision-video.c:1527 usb_probe_interface+0x305/0x7a0 /drivers/usb/core/driver.c:361 really_probe+0x281/0x660 /drivers/base/dd.c:509 driver_probe_device+0x104/0x210 /drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 /drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 /drivers/base/bus.c:454 __device_attach+0x217/0x360 /drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 /drivers/base/bus.c:514 device_add+0xae6/0x16f0 /drivers/base/core.c:2111 usb_set_configuration+0xdf6/0x1670 /drivers/usb/core/message.c:2023 generic_probe+0x9d/0xd5 /drivers/usb/core/generic.c:210 usb_probe_device+0x99/0x100 /drivers/usb/core/driver.c:266 really_probe+0x281/0x660 /drivers/base/dd.c:509 driver_probe_device+0x104/0x210 /drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 /drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 /drivers/base/bus.c:454 __device_attach+0x217/0x360 /drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 /drivers/base/bus.c:514 device_add+0xae6/0x16f0 /drivers/base/core.c:2111 usb_new_device.cold+0x6a4/0xe61 /drivers/usb/core/hub.c:2536 hub_port_connect /drivers/usb/core/hub.c:5098 [inline] hub_port_connect_change /drivers/usb/core/hub.c:5213 [inline] port_event /drivers/usb/core/hub.c:5359 [inline] hub_event+0x1abd/0x3550 /drivers/usb/core/hub.c:5441 process_one_work+0x905/0x1570 /kernel/workqueue.c:2269 worker_thread+0x96/0xe20 /kernel/workqueue.c:2415 kthread+0x30b/0x410 /kernel/kthread.c:255 ret_from_fork+0x24/0x30 /arch/x86/entry/entry_64.S:352 Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for h
kernel BUG at drivers/usb/wusbcore/wusbhc.c:LINE!
Hello, syzbot found the following crash on: HEAD commit:6a3599ce usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=1417be9460 kernel config: https://syzkaller.appspot.com/x/.config?x=700ca426ab83faae dashboard link: https://syzkaller.appspot.com/bug?extid=fd2bd7df88c606eea4ef compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15d5d25c60 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15c2935860 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+fd2bd7df88c606eea...@syzkaller.appspotmail.com usb 1-1: BUG? WUSB host has no security descriptors hwa-hc 1-1:0.66: Wireless USB HWA host controller hwa-hc 1-1:0.66: new USB bus registered, assigned bus number 11 hwa-hc 1-1:0.66: Cannot set WUSB Cluster ID to 0xfe: -71 hwa-hc 1-1:0.66: Wireless USB Cluster ID set to 0xfe [ cut here ] kernel BUG at drivers/usb/wusbcore/wusbhc.c:385! invalid opcode: [#1] SMP KASAN CPU: 1 PID: 21 Comm: kworker/1:1 Not tainted 5.2.0-rc6+ #15 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:wusb_cluster_id_put+0x6b/0x80 /drivers/usb/wusbcore/wusbhc.c:385 Code: 7b 9d ce fd 40 84 ed 74 23 e8 41 9c ce fd f0 48 0f b3 1d e8 d6 0e 06 5b 48 c7 c7 60 1b 06 87 5d e9 8a 3c e9 01 e8 25 9c ce fd <0f> 0b e8 1e 9c ce fd 0f 0b eb d4 66 2e 0f 1f 84 00 00 00 00 00 41 RSP: 0018:8881d9eff0e8 EFLAGS: 00010293 RAX: 8881d9e36000 RBX: RCX: 836e3f37 RDX: RSI: 836e3f8b RDI: 0001 RBP: 00fe R08: 8881d9e36000 R09: R10: R11: R12: ffb9 R13: 8881d4a52600 R14: 8881d0b5d530 R15: 00fe FS: () GS:8881db30() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7efcea69e000 CR3: 0001d4f3a000 CR4: 001406e0 Call Trace: hwahc_op_start.cold+0x159/0x183 /drivers/usb/host/hwa-hc.c:162 usb_add_hcd.cold+0xaac/0x15a1 /drivers/usb/core/hcd.c:2887 hwahc_probe.cold+0xef/0x48b /drivers/usb/host/hwa-hc.c:810 usb_probe_interface+0x305/0x7a0 /drivers/usb/core/driver.c:361 really_probe+0x281/0x660 /drivers/base/dd.c:509 driver_probe_device+0x104/0x210 /drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 /drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 /drivers/base/bus.c:454 __device_attach+0x217/0x360 /drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 /drivers/base/bus.c:514 device_add+0xae6/0x16f0 /drivers/base/core.c:2111 usb_set_configuration+0xdf6/0x1670 /drivers/usb/core/message.c:2023 generic_probe+0x9d/0xd5 /drivers/usb/core/generic.c:210 usb_probe_device+0x99/0x100 /drivers/usb/core/driver.c:266 really_probe+0x281/0x660 /drivers/base/dd.c:509 driver_probe_device+0x104/0x210 /drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 /drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 /drivers/base/bus.c:454 __device_attach+0x217/0x360 /drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 /drivers/base/bus.c:514 device_add+0xae6/0x16f0 /drivers/base/core.c:2111 usb_new_device.cold+0x6a4/0xe61 /drivers/usb/core/hub.c:2536 hub_port_connect /drivers/usb/core/hub.c:5098 [inline] hub_port_connect_change /drivers/usb/core/hub.c:5213 [inline] port_event /drivers/usb/core/hub.c:5359 [inline] hub_event+0x1abd/0x3550 /drivers/usb/core/hub.c:5441 process_one_work+0x905/0x1570 /kernel/workqueue.c:2269 worker_thread+0x96/0xe20 /kernel/workqueue.c:2415 kthread+0x30b/0x410 /kernel/kthread.c:255 ret_from_fork+0x24/0x30 /arch/x86/entry/entry_64.S:352 Modules linked in: ---[ end trace 328f1b9a8fbb35b6 ]--- RIP: 0010:wusb_cluster_id_put+0x6b/0x80 /drivers/usb/wusbcore/wusbhc.c:385 Code: 7b 9d ce fd 40 84 ed 74 23 e8 41 9c ce fd f0 48 0f b3 1d e8 d6 0e 06 5b 48 c7 c7 60 1b 06 87 5d e9 8a 3c e9 01 e8 25 9c ce fd <0f> 0b e8 1e 9c ce fd 0f 0b eb d4 66 2e 0f 1f 84 00 00 00 00 00 41 RSP: 0018:8881d9eff0e8 EFLAGS: 00010293 RAX: 8881d9e36000 RBX: RCX: 836e3f37 RDX: RSI: 836e3f8b RDI: 0001 RBP: 00fe R08: 8881d9e36000 R09: R10: R11: R12: ffb9 R13: 8881d4a52600 R14: 8881d0b5d530 R15: 00fe FS: () GS:8881db30() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7efcea69e000 CR3: 0001d4f3a000 CR4: 001406e0 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report.
INFO: task hung in hwrng_unregister
Hello, syzbot found the following crash on: HEAD commit:6a3599ce usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=1266ca6460 kernel config: https://syzkaller.appspot.com/x/.config?x=700ca426ab83faae dashboard link: https://syzkaller.appspot.com/bug?extid=823cb2bdae0c63b2cb9f compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=143d46f460 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1789853fa0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+823cb2bdae0c63b2c...@syzkaller.appspotmail.com INFO: task kworker/0:0:5 blocked for more than 143 seconds. Not tainted 5.2.0-rc6+ #15 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/0:0 D26088 5 2 0x80004000 Workqueue: usb_hub_wq hub_event Call Trace: schedule+0x96/0x240 /kernel/sched/core.c:3509 schedule_timeout+0x682/0xb20 /kernel/time/timer.c:1783 do_wait_for_common /kernel/sched/completion.c:83 [inline] __wait_for_common /kernel/sched/completion.c:104 [inline] wait_for_common /kernel/sched/completion.c:115 [inline] wait_for_completion+0x26f/0x3c0 /kernel/sched/completion.c:136 kthread_stop+0xe6/0x5a0 /kernel/kthread.c:559 hwrng_unregister+0x190/0x210 /drivers/char/hw_random/core.c:535 chaoskey_disconnect+0x1b2/0x200 /drivers/usb/misc/chaoskey.c:231 usb_unbind_interface+0x1bd/0x8a0 /drivers/usb/core/driver.c:423 __device_release_driver /drivers/base/dd.c:1081 [inline] device_release_driver_internal+0x404/0x4c0 /drivers/base/dd.c:1112 bus_remove_device+0x2dc/0x4a0 /drivers/base/bus.c:556 device_del+0x460/0xb80 /drivers/base/core.c:2274 usb_disable_device+0x211/0x690 /drivers/usb/core/message.c:1237 usb_disconnect+0x284/0x830 /drivers/usb/core/hub.c:2199 hub_port_connect /drivers/usb/core/hub.c:4949 [inline] hub_port_connect_change /drivers/usb/core/hub.c:5213 [inline] port_event /drivers/usb/core/hub.c:5359 [inline] hub_event+0x13bd/0x3550 /drivers/usb/core/hub.c:5441 process_one_work+0x905/0x1570 /kernel/workqueue.c:2269 process_scheduled_works /kernel/workqueue.c:2331 [inline] worker_thread+0x7ab/0xe20 /kernel/workqueue.c:2417 kthread+0x30b/0x410 /kernel/kthread.c:255 ret_from_fork+0x24/0x30 /arch/x86/entry/entry_64.S:352 INFO: task kworker/1:1:21 blocked for more than 143 seconds. Not tainted 5.2.0-rc6+ #15 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/1:1 D2557621 2 0x80004000 Workqueue: usb_hub_wq hub_event Call Trace: schedule+0x96/0x240 /kernel/sched/core.c:3509 schedule_timeout+0x682/0xb20 /kernel/time/timer.c:1783 do_wait_for_common /kernel/sched/completion.c:83 [inline] __wait_for_common /kernel/sched/completion.c:104 [inline] wait_for_common /kernel/sched/completion.c:115 [inline] wait_for_completion+0x26f/0x3c0 /kernel/sched/completion.c:136 kthread_stop+0xe6/0x5a0 /kernel/kthread.c:559 hwrng_unregister+0x190/0x210 /drivers/char/hw_random/core.c:535 chaoskey_disconnect+0x1b2/0x200 /drivers/usb/misc/chaoskey.c:231 usb_unbind_interface+0x1bd/0x8a0 /drivers/usb/core/driver.c:423 __device_release_driver /drivers/base/dd.c:1081 [inline] device_release_driver_internal+0x404/0x4c0 /drivers/base/dd.c:1112 bus_remove_device+0x2dc/0x4a0 /drivers/base/bus.c:556 device_del+0x460/0xb80 /drivers/base/core.c:2274 usb_disable_device+0x211/0x690 /drivers/usb/core/message.c:1237 usb_disconnect+0x284/0x830 /drivers/usb/core/hub.c:2199 hub_port_connect /drivers/usb/core/hub.c:4949 [inline] hub_port_connect_change /drivers/usb/core/hub.c:5213 [inline] port_event /drivers/usb/core/hub.c:5359 [inline] hub_event+0x13bd/0x3550 /drivers/usb/core/hub.c:5441 process_one_work+0x905/0x1570 /kernel/workqueue.c:2269 process_scheduled_works /kernel/workqueue.c:2331 [inline] worker_thread+0x7ab/0xe20 /kernel/workqueue.c:2417 kthread+0x30b/0x410 /kernel/kthread.c:255 ret_from_fork+0x24/0x30 /arch/x86/entry/entry_64.S:352 INFO: task kworker/0:2:107 blocked for more than 143 seconds. Not tainted 5.2.0-rc6+ #15 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/0:2 D25688 107 2 0x80004000 Workqueue: usb_hub_wq hub_event Call Trace: schedule+0x96/0x240 /kernel/sched/core.c:3509 schedule_timeout+0x682/0xb20 /kernel/time/timer.c:1783 do_wait_for_common /kernel/sched/completion.c:83 [inline] __wait_for_common /kernel/sched/completion.c:104 [inline] wait_for_common /kernel/sched/completion.c:115 [inline] wait_for_completion+0x26f/0x3c0 /kernel/sched/completion.c:136 kthread_stop+0xe6/0x5a0 /kernel/kthread.c:559 hwrng_unregister+0x190/0x210 /drivers/char/hw_random/core.c:535 chaoskey_disconnect+0x1b2/0x200 /drivers/usb/misc/chaoskey.c:231 usb_unbind_interface+0x1bd/0x8a0 /drivers/usb/core/driver.c:423 __device_release_driver /drivers
WARNING in ati_remote_sendpacket/usb_submit_urb
Hello, syzbot found the following crash on: HEAD commit:6a3599ce usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=14a3cf4c60 kernel config: https://syzkaller.appspot.com/x/.config?x=700ca426ab83faae dashboard link: https://syzkaller.appspot.com/bug?extid=998261c2ae5932458f6c compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12bb21f460 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15cf5c6460 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+998261c2ae5932458...@syzkaller.appspotmail.com usb 1-1: config 0 interface 7 altsetting 0 endpoint 0xF has invalid maxpacket 368, setting to 64 usb 1-1: New USB device found, idVendor=0bc7, idProduct=0003, bcdDevice=2f.f7 usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 1-1: config 0 descriptor?? [ cut here ] usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 1 PID: 21 at drivers/usb/core/urb.c:477 usb_submit_urb+0x1188/0x13b0 /drivers/usb/core/urb.c:477 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 21 Comm: kworker/1:1 Not tainted 5.2.0-rc6+ #15 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack /lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e /lib/dump_stack.c:113 panic+0x292/0x6c9 /kernel/panic.c:219 __warn.cold+0x20/0x4b /kernel/panic.c:576 report_bug+0x262/0x2a0 /lib/bug.c:186 fixup_bug /arch/x86/kernel/traps.c:179 [inline] fixup_bug /arch/x86/kernel/traps.c:174 [inline] do_error_trap+0x12b/0x1e0 /arch/x86/kernel/traps.c:272 do_invalid_op+0x32/0x40 /arch/x86/kernel/traps.c:291 invalid_op+0x14/0x20 /arch/x86/entry/entry_64.S:986 RIP: 0010:usb_submit_urb+0x1188/0x13b0 /drivers/usb/core/urb.c:477 Code: 4d 85 ed 74 2c e8 f8 d3 f4 fd 4c 89 f7 e8 a0 51 1c ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 00 0e f7 85 e8 83 98 ca fd <0f> 0b e9 20 f4 ff ff e8 cc d3 f4 fd 4c 89 f2 48 b8 00 00 00 00 00 RSP: 0018:8881d9eff130 EFLAGS: 00010282 RAX: RBX: 0003 RCX: RDX: RSI: 8127ef3d RDI: ed103b3dfe18 RBP: 8881d40c7150 R08: 8881d9e36000 R09: R10: R11: R12: 0001 R13: 8881c7bb6450 R14: 8881d05d3c20 R15: 8881d409da00 ati_remote_sendpacket+0x1ee/0x540 /drivers/media/rc/ati_remote.c:416 ati_remote_initialize /drivers/media/rc/ati_remote.c:797 [inline] ati_remote_probe+0x1254/0x1fda /drivers/media/rc/ati_remote.c:889 usb_probe_interface+0x305/0x7a0 /drivers/usb/core/driver.c:361 really_probe+0x281/0x660 /drivers/base/dd.c:509 driver_probe_device+0x104/0x210 /drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 /drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 /drivers/base/bus.c:454 __device_attach+0x217/0x360 /drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 /drivers/base/bus.c:514 device_add+0xae6/0x16f0 /drivers/base/core.c:2111 usb_set_configuration+0xdf6/0x1670 /drivers/usb/core/message.c:2023 generic_probe+0x9d/0xd5 /drivers/usb/core/generic.c:210 usb_probe_device+0x99/0x100 /drivers/usb/core/driver.c:266 really_probe+0x281/0x660 /drivers/base/dd.c:509 driver_probe_device+0x104/0x210 /drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 /drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 /drivers/base/bus.c:454 __device_attach+0x217/0x360 /drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 /drivers/base/bus.c:514 device_add+0xae6/0x16f0 /drivers/base/core.c:2111 usb_new_device.cold+0x6a4/0xe61 /drivers/usb/core/hub.c:2536 hub_port_connect /drivers/usb/core/hub.c:5098 [inline] hub_port_connect_change /drivers/usb/core/hub.c:5213 [inline] port_event /drivers/usb/core/hub.c:5359 [inline] hub_event+0x1abd/0x3550 /drivers/usb/core/hub.c:5441 process_one_work+0x905/0x1570 /kernel/workqueue.c:2269 worker_thread+0x96/0xe20 /kernel/workqueue.c:2415 kthread+0x30b/0x410 /kernel/kthread.c:255 ret_from_fork+0x24/0x30 /arch/x86/entry/entry_64.S:352 Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
WARNING: ODEBUG bug in smsusb_term_device
Hello, syzbot found the following crash on: HEAD commit:6a3599ce usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=14d4a74c60 kernel config: https://syzkaller.appspot.com/x/.config?x=700ca426ab83faae dashboard link: https://syzkaller.appspot.com/bug?extid=25ddf1bb485cd9400ca4 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13fc4d3460 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13e7b67860 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+25ddf1bb485cd9400...@syzkaller.appspotmail.com smsusb:smsusb_init_device: smscore_start_device(...) failed [ cut here ] ODEBUG: free active (active state 0) object type: work_struct hint: do_submit_urb+0x0/0x60 /drivers/media/usb/siano/smsusb.c:155 WARNING: CPU: 1 PID: 22 at lib/debugobjects.c:325 debug_print_object+0x160/0x250 /lib/debugobjects.c:325 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 22 Comm: kworker/1:1 Not tainted 5.2.0-rc6+ #15 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack /lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e /lib/dump_stack.c:113 panic+0x292/0x6c9 /kernel/panic.c:219 __warn.cold+0x20/0x4b /kernel/panic.c:576 report_bug+0x262/0x2a0 /lib/bug.c:186 fixup_bug /arch/x86/kernel/traps.c:179 [inline] fixup_bug /arch/x86/kernel/traps.c:174 [inline] do_error_trap+0x12b/0x1e0 /arch/x86/kernel/traps.c:272 do_invalid_op+0x32/0x40 /arch/x86/kernel/traps.c:291 invalid_op+0x14/0x20 /arch/x86/entry/entry_64.S:986 RIP: 0010:debug_print_object+0x160/0x250 /lib/debugobjects.c:325 Code: dd e0 16 ba 85 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 bf 00 00 00 48 8b 14 dd e0 16 ba 85 48 c7 c7 c0 0c ba 85 e8 db c7 33 ff <0f> 0b 83 05 03 6e 86 05 01 48 83 c4 20 5b 5d 41 5c 41 5d c3 48 89 RSP: 0018:8881d9f8efb8 EFLAGS: 00010082 RAX: RBX: 0003 RCX: RDX: RSI: 8127ef3d RDI: ed103b3f1de9 RBP: 0001 R08: 8881d9f8 R09: ed103b663ed7 R10: ed103b663ed6 R11: 8881db31f6b7 R12: 86ac9ea0 R13: 81187f60 R14: 88f0e3e8 R15: 8881cf581bc0 __debug_check_no_obj_freed /lib/debugobjects.c:785 [inline] debug_check_no_obj_freed+0x2a3/0x42e /lib/debugobjects.c:817 slab_free_hook /mm/slub.c:1418 [inline] slab_free_freelist_hook /mm/slub.c:1448 [inline] slab_free /mm/slub.c:2994 [inline] kfree+0x101/0x280 /mm/slub.c:3949 smsusb_term_device+0xc2/0x120 /drivers/media/usb/siano/smsusb.c:350 smsusb_init_device+0x987/0x9d5 /drivers/media/usb/siano/smsusb.c:487 smsusb_probe+0x986/0xa24 /drivers/media/usb/siano/smsusb.c:566 usb_probe_interface+0x305/0x7a0 /drivers/usb/core/driver.c:361 really_probe+0x281/0x660 /drivers/base/dd.c:509 driver_probe_device+0x104/0x210 /drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 /drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 /drivers/base/bus.c:454 __device_attach+0x217/0x360 /drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 /drivers/base/bus.c:514 device_add+0xae6/0x16f0 /drivers/base/core.c:2111 usb_set_configuration+0xdf6/0x1670 /drivers/usb/core/message.c:2023 generic_probe+0x9d/0xd5 /drivers/usb/core/generic.c:210 usb_probe_device+0x99/0x100 /drivers/usb/core/driver.c:266 really_probe+0x281/0x660 /drivers/base/dd.c:509 driver_probe_device+0x104/0x210 /drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 /drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 /drivers/base/bus.c:454 __device_attach+0x217/0x360 /drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 /drivers/base/bus.c:514 device_add+0xae6/0x16f0 /drivers/base/core.c:2111 usb_new_device.cold+0x6a4/0xe61 /drivers/usb/core/hub.c:2536 hub_port_connect /drivers/usb/core/hub.c:5098 [inline] hub_port_connect_change /drivers/usb/core/hub.c:5213 [inline] port_event /drivers/usb/core/hub.c:5359 [inline] hub_event+0x1abd/0x3550 /drivers/usb/core/hub.c:5441 process_one_work+0x905/0x1570 /kernel/workqueue.c:2269 worker_thread+0x96/0xe20 /kernel/workqueue.c:2415 kthread+0x30b/0x410 /kernel/kthread.c:255 ret_from_fork+0x24/0x30 /arch/x86/entry/entry_64.S:352 == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
INFO: trying to register non-static key in usbtouch_open
Hello, syzbot found the following crash on: HEAD commit:6a3599ce usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=1633092060 kernel config: https://syzkaller.appspot.com/x/.config?x=700ca426ab83faae dashboard link: https://syzkaller.appspot.com/bug?extid=f9c21a30eb9d374e30c1 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17e5ee7860 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10e4a74c60 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+f9c21a30eb9d374e3...@syzkaller.appspotmail.com INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 0 PID: 1737 Comm: syz-executor481 Not tainted 5.2.0-rc6+ #15 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack /lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e /lib/dump_stack.c:113 assign_lock_key /kernel/locking/lockdep.c:775 [inline] register_lock_class+0x11ae/0x1240 /kernel/locking/lockdep.c:1084 __lock_acquire+0x11d/0x5340 /kernel/locking/lockdep.c:3674 lock_acquire+0x100/0x2b0 /kernel/locking/lockdep.c:4303 __mutex_lock_common /kernel/locking/mutex.c:926 [inline] __mutex_lock+0xf9/0x12b0 /kernel/locking/mutex.c:1073 usbtouch_open+0x101/0x310 /drivers/input/touchscreen/usbtouchscreen.c:1537 input_open_device+0x170/0x280 /drivers/input/input.c:607 evdev_open_device /drivers/input/evdev.c:433 [inline] evdev_open+0x3fe/0x510 /drivers/input/evdev.c:518 chrdev_open+0x219/0x5c0 /fs/char_dev.c:413 do_dentry_open+0x497/0x1040 /fs/open.c:778 do_last /fs/namei.c:3416 [inline] path_openat+0x1430/0x3ff0 /fs/namei.c:3533 do_filp_open+0x1a1/0x280 /fs/namei.c:3563 do_sys_open+0x3c0/0x580 /fs/open.c:1070 do_syscall_64+0xb7/0x560 /arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4011f0 Code: 01 f0 ff ff 0f 83 00 0b 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 83 3d 9d 4b 2d 00 00 75 14 b8 02 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 d4 0a 00 00 c3 48 83 ec 08 e8 3a 00 00 00 RSP: 002b:7ffdc8662728 EFLAGS: 0246 ORIG_RAX: 0002 RAX: ffda RBX: RCX: 004011f0 RDX: RSI: 0002 RDI: 7ffdc8662730 RBP: 6667 R08: 000f R09: 0023 R10: 0075 R11: 0246 R12: 00402150 R13: 004021e0 R14: R15: --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
KASAN: use-after-free Read in usbhid_power
Hello, syzbot found the following crash on: HEAD commit:6a3599ce usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=11b13e7860 kernel config: https://syzkaller.appspot.com/x/.config?x=700ca426ab83faae dashboard link: https://syzkaller.appspot.com/bug?extid=ef5de9c4f99c4edb4e49 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1548221060 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1139b07c60 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+ef5de9c4f99c4edb4...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in usbhid_power+0xca/0xe0 /drivers/hid/usbhid/hid-core.c:1234 Read of size 8 at addr 8881ce8a4008 by task syz-executor373/1763 CPU: 0 PID: 1763 Comm: syz-executor373 Not tainted 5.2.0-rc6+ #15 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack /lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e /lib/dump_stack.c:113 print_address_description+0x67/0x231 /mm/kasan/report.c:188 __kasan_report.cold+0x1a/0x32 /mm/kasan/report.c:317 kasan_report+0xe/0x20 /mm/kasan/common.c:614 usbhid_power+0xca/0xe0 /drivers/hid/usbhid/hid-core.c:1234 hid_hw_power /./include/linux/hid.h:1038 [inline] hidraw_open+0x20d/0x740 /drivers/hid/hidraw.c:282 chrdev_open+0x219/0x5c0 /fs/char_dev.c:413 do_dentry_open+0x497/0x1040 /fs/open.c:778 do_last /fs/namei.c:3416 [inline] path_openat+0x1430/0x3ff0 /fs/namei.c:3533 do_filp_open+0x1a1/0x280 /fs/namei.c:3563 do_sys_open+0x3c0/0x580 /fs/open.c:1070 do_syscall_64+0xb7/0x560 /arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x401ad0 Code: 01 f0 ff ff 0f 83 c0 0b 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 83 3d fd 5b 2d 00 00 75 14 b8 02 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 94 0b 00 00 c3 48 83 ec 08 e8 fa 00 00 00 RSP: 002b:7378ac48 EFLAGS: 0246 ORIG_RAX: 0002 RAX: ffda RBX: RCX: 00401ad0 RDX: RSI: 0800 RDI: 7378ac50 RBP: 6667 R08: 000f R09: R10: R11: 0246 R12: 00402af0 R13: 00402b80 R14: R15: Allocated by task 21: save_stack+0x1b/0x80 /mm/kasan/common.c:71 set_track /mm/kasan/common.c:79 [inline] __kasan_kmalloc /mm/kasan/common.c:489 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 /mm/kasan/common.c:462 slab_post_alloc_hook /mm/slab.h:437 [inline] slab_alloc_node /mm/slub.c:2748 [inline] __kmalloc_node_track_caller+0xee/0x370 /mm/slub.c:4363 __kmalloc_reserve.isra.0+0x39/0xe0 /net/core/skbuff.c:138 __alloc_skb+0xef/0x5a0 /net/core/skbuff.c:206 alloc_skb /./include/linux/skbuff.h:1054 [inline] alloc_uevent_skb+0x7b/0x210 /lib/kobject_uevent.c:289 uevent_net_broadcast_untagged /lib/kobject_uevent.c:325 [inline] kobject_uevent_net_broadcast /lib/kobject_uevent.c:408 [inline] kobject_uevent_env+0x8ee/0x1150 /lib/kobject_uevent.c:592 device_add+0xade/0x16f0 /drivers/base/core.c:2110 usb_set_configuration+0xdf6/0x1670 /drivers/usb/core/message.c:2023 generic_probe+0x9d/0xd5 /drivers/usb/core/generic.c:210 usb_probe_device+0x99/0x100 /drivers/usb/core/driver.c:266 really_probe+0x281/0x660 /drivers/base/dd.c:509 driver_probe_device+0x104/0x210 /drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 /drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 /drivers/base/bus.c:454 __device_attach+0x217/0x360 /drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 /drivers/base/bus.c:514 device_add+0xae6/0x16f0 /drivers/base/core.c:2111 usb_new_device.cold+0x6a4/0xe61 /drivers/usb/core/hub.c:2536 hub_port_connect /drivers/usb/core/hub.c:5098 [inline] hub_port_connect_change /drivers/usb/core/hub.c:5213 [inline] port_event /drivers/usb/core/hub.c:5359 [inline] hub_event+0x1abd/0x3550 /drivers/usb/core/hub.c:5441 process_one_work+0x905/0x1570 /kernel/workqueue.c:2269 process_scheduled_works /kernel/workqueue.c:2331 [inline] worker_thread+0x7ab/0xe20 /kernel/workqueue.c:2417 kthread+0x30b/0x410 /kernel/kthread.c:255 ret_from_fork+0x24/0x30 /arch/x86/entry/entry_64.S:352 Freed by task 243: save_stack+0x1b/0x80 /mm/kasan/common.c:71 set_track /mm/kasan/common.c:79 [inline] __kasan_slab_free+0x130/0x180 /mm/kasan/common.c:451 slab_free_hook /mm/slub.c:1421 [inline] slab_free_freelist_hook /mm/slub.c:1448 [inline] slab_free /mm/slub.c:2994 [inline] kfree+0xd7/0x280 /mm/slub.c:3949 skb_free_head+0x8b/0xa0 /net/core/skbuff.c:588 skb_release_data+0x41f/0x7c0 /net/core/skbuff.c:608 skb_release_all+0x46/0x60 /net/core/skbuff.c:662 __kfree_skb /net/core/skbuff.c:676 [inline] consume_skb /net/
Re: High-Impact: xhci_hid - "Not enough bandwidth for new device state"
On Tue, Jul 23, 2019 at 03:12:53PM +0200, Frank Bergmann wrote: > Hi Greg, > > > Thank you for answering! You are my hero. > > > > not much to be done [...] bandwidth > > [...] we can't do the impossible here > > > It is not the bandwidth! That would be easy... > > > 1. USB 3.0 on my Dell XPS 15 9370 has 10GB/s, that's enough for a Webcam > (USB 2.0) plus some audio... Are you sure? It all depends on what that devices are asking for. Remember USB 2 devices suck the bandwidth of a USB connection like a starving sponge. > 2. It works after a reboot for a while, if I first add the Webcam and > then(!) start the VM (VMware Player or Workstation 15) It depends on the order in which you ask for resources. I have no idea what vmware does, and how it is faking all of this out by possibly using kernel drivers or userspace interactions. So I wouldn't use that as an example of anything working well :) > 3. It worked in Windows 7 and Windows 10 (WebCam plus audio from VMware > Player (Windows versions)) before I switched to Ubuntu 18.04. Windows 7, like older versions of Linux, would not try to calculate the bandwidth requirements ahead of time, and would just try to work. That causes problems with dropped packets and other fun issues. Linux solved this in newer releases by doing the calculations "up front" and you are seeing the result. You always were going over the max limit, but when using the device, "getting lucky". I think Windows 10 also does what Windows 7 did, but am not quite sure. Try asking on a Windows list... > 4. RedHad guys acknowledged the bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1411604 > > > > Many people have that configuration > > > Please search Google for 'USB "Not enough bandwidth for new device state"'. > You will find 650 results with quite specific and similar error > descriptions. It all comes down to the configuration of your devices and root hubs and controller. Yes, lots of people can duplicate this issue, but then again, that's why we put the check in there, to give people a chance to understand why things would later stop working. > The bug seems to occur in the isochronic transmission part of USB 3.0. > Somebody suspected it occurs if there are two devices trying to transmit at > the same time (WebCam + VM audio). Probably. > > separate USB hub > > > Already tried that and zillions of other combinations. In particular I tried > with no USB hub at all, just WebCam + VM and no other hardware. Root hub. The device that connects the PCI device to the USB bus. On some laptops there is one root hub per USB port, on others, only 1 root hub for all plugs together. It depends on your system. If you have a desktop system, try plugging in a new PCI USB controller, that is a root hub device. > After downgrading to USB 2.0 via BIOS it worked, though... But that's not > possible for other reasons. Yes, that is a normal solution as then your USB 3 devices do not ask for "too much" bandwidth. There's also issues with having to reserve ahead of time the max bandwidth possible for a 2.0 device on a 3.0 bus that causes problems as you can see. It's not a simple problem and is always easier to just get a different USB controller as you will end up having issues on other operating systems as well, if they don't try to do the reservations ahead of time, it's just harder to notice. sorry, greg k-h
Re: [PATCH v2 1/2] usbip: Skip DMA mapping and unmapping for urb at vhci
On Mon, Jul 22, 2019 at 02:26:42PM -0600, shuah wrote:
> Hi Suwan,
>
> On 7/5/19 10:43 AM, Suwan Kim wrote:
> > vhci doesn’t do DMA for remote device. Actually, the real DMA
> > operation is done by network card driver. vhci just passes virtual
> > address of the buffer to the network stack, so vhci doesn’t use and
> > need dma address of the buffer of the URB.
> >
> > When it comes to supporting SG for vhci, it is useful to use native
> > SG list (urb->num_sgs) instead of mapped SG list because DMA mapping
> > fnuction can adjust the number of SG list (urb->num_mapped_sgs).
> >
> > But HCD provides DMA mapping and unmapping function by default.
> > Moreover, it causes unnecessary DMA mapping and unmapping which
> > will be done again at the NIC driver and it wastes CPU cycles.
> > So, implement map_urb_for_dma and unmap_urb_for_dma function for
> > vhci in order to skip the DMA mapping and unmapping procedure.
> >
> > To support SG, vhci_map_urb_for_dma() sets URB_DMA_MAP_SG flag in
> > urb->transfer_flags if URB has SG list and this flag will tell the
> > stub driver to use SG list.
> >
> > Signed-off-by: Suwan Kim
> > ---
> > drivers/usb/usbip/vhci_hcd.c | 19 +++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
> > index 000ab7225717..14fc6d9f4e6a 100644
> > --- a/drivers/usb/usbip/vhci_hcd.c
> > +++ b/drivers/usb/usbip/vhci_hcd.c
> > @@ -1288,6 +1288,22 @@ static int vhci_free_streams(struct usb_hcd *hcd,
> > struct usb_device *udev,
> > return 0;
> > }
> > +static int vhci_map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb,
> > + gfp_t mem_flags)
> > +{
> > + dev_dbg(hcd->self.controller, "vhci does not map urb for dma\n");
> > +
> > + if (urb->num_sgs)
> > + urb->transfer_flags |= URB_DMA_MAP_SG;
> > +
>
> Shouldn't this be part of patch 2. The debug message saying "no map"
> and setting flag doesn't make sense.
I think you are right. Setting flag should be in patch 2. Thank you
for pointing out :)
I will remove unnecessary debug messages and move setting flag to
patch 2.
> > + return 0;
>
> This should be a tab and no spaces btw. chekpatch isn't happy.
>
> > +}
> > +
> > +static void vhci_unmap_urb_for_dma(struct usb_hcd *hcd, struct urb *urb)
> > +{
> > + dev_dbg(hcd->self.controller, "vhci does not unmap urb for dma\n");
>
> This should be a tab and no spaces btw. chekpatch isn't happy.
>
>
> WARNING: please, no spaces at the start of a line
> #144: FILE: drivers/usb/usbip/vhci_hcd.c:1299:
> + return 0;$
>
> WARNING: please, no spaces at the start of a line
> #149: FILE: drivers/usb/usbip/vhci_hcd.c:1304:
> + dev_dbg(hcd->self.controller, "vhci does not unmap urb for dma\n");$
>
> total: 0 errors, 2 warnings, 31 lines checked
I'm sorry for my fault. I will check it.
Regards,
Suwan Kim
Re: [PATCH v2 2/2] usbip: Implement SG support to vhci
On Mon, Jul 22, 2019 at 09:51:30PM -0600, shuah wrote:
> On 7/5/19 10:43 AM, Suwan Kim wrote:
> > There are bugs on vhci with usb 3.0 storage device. Originally, vhci
> > doesn't supported SG, so USB storage driver on vhci breaks SG list
>
> grammar - Currently vhci doesn't support?
Yes, that is what I intended. Please excuse my poor english.
> > into multiple URBs and it causes error that a transfer got terminated
> > too early because the transfer length for one of the URBs was not
> > divisible by the maxpacket size.
> >
> > In this patch, vhci basically support SG and it sends each SG list
>
> What does basically support mean here? Do you mean basic support?
What I intended was that vhci supports SG regardless of whether the
server's host controller supports SG or not, because stub driver
splits SG list into several URBs if the server's host controller
doesn't support SG. I will rewrite the description to make it more
clear.
> > entry to the stub driver. Then, the stub driver sees the total length
> > of the buffer and allocates SG table and pages according to the total
> > buffer length calling sgl_alloc(). After the stub driver receives
> > completed URB, it again sends each SG list entry to vhci.
> >
> > If HCD of the server doesn't support SG, the stub driver breaks a
> > single SG reqeust into several URBs and submit them to the server's
> > HCD. When all the split URBs are completed, the stub driver
> > reassembles the URBs into a single return command and sends it to
> > vhci.
> >
> > Signed-off-by: Suwan Kim
> > ---
> > drivers/usb/usbip/stub.h | 7 +-
> > drivers/usb/usbip/stub_main.c| 52 +---
> > drivers/usb/usbip/stub_rx.c | 207 ++-
> > drivers/usb/usbip/stub_tx.c | 108 +++-
> > drivers/usb/usbip/usbip_common.c | 60 +++--
> > drivers/usb/usbip/vhci_hcd.c | 10 +-
> > drivers/usb/usbip/vhci_tx.c | 49 ++--
> > 7 files changed, 372 insertions(+), 121 deletions(-)
> >
>
> btw checkpatch isn't very happy with this patch. A few coding style
> issues. Please run checkpatch before sending patches.
I'm sorry for sending it without running checkpatch.
I will fix all problems with checkpatch and resend v3.
> > diff --git a/drivers/usb/usbip/stub.h b/drivers/usb/usbip/stub.h
> > index 35618ceb2791..d11270560c24 100644
> > --- a/drivers/usb/usbip/stub.h
> > +++ b/drivers/usb/usbip/stub.h
> > @@ -52,7 +52,11 @@ struct stub_priv {
> > unsigned long seqnum;
> > struct list_head list;
> > struct stub_device *sdev;
> > - struct urb *urb;
> > + struct urb **urbs;
> > + struct scatterlist *sgl;
> > + int num_urbs;
> > + int completed_urbs;
> > + int urb_status;
> > int unlinking;
> > };
> > @@ -86,6 +90,7 @@ extern struct usb_device_driver stub_driver;
> > struct bus_id_priv *get_busid_priv(const char *busid);
> > void put_busid_priv(struct bus_id_priv *bid);
> > int del_match_busid(char *busid);
> > +void stub_free_priv_and_urb(struct stub_priv *priv);
> > void stub_device_cleanup_urbs(struct stub_device *sdev);
> > /* stub_rx.c */
> > diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c
> > index 2e4bfccd4bfc..dec5af9f7179 100644
> > --- a/drivers/usb/usbip/stub_main.c
> > +++ b/drivers/usb/usbip/stub_main.c
> > @@ -6,6 +6,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include "usbip_common.h"
> > #include "stub.h"
> > @@ -288,6 +289,39 @@ static struct stub_priv
> > *stub_priv_pop_from_listhead(struct list_head *listhead)
> > return NULL;
> > }
> > +void stub_free_priv_and_urb(struct stub_priv *priv)
> > +{
> > + struct urb *urb;
> > + int i;
> > +
> > + for (i = 0; i < priv->num_urbs; i++) {
> > + urb = priv->urbs[i];
> > + if (urb->setup_packet) {
> > + kfree(urb->setup_packet);
> > + urb->setup_packet = NULL;
> > + }
> > +
>
> You don't need urb->setup_packet null check. kfree() is safe
> to call with null pointer. btw checkpatch tells you this.
Ok. I will remove null check.
> > + if (urb->transfer_buffer && !priv->sgl) {
>
> Is this conditional necessary? Why are you checking priv->sgl?
> Are there cases where you have memory leak? Is there a case
> when urb->transfer_buffer valid when priv->sgl isn't null?
In my implementation, if URB has an SG list, whether SG is supported
by the server's host controller or not, stub driver allocates SG list
and pages calling sg_alloc().
At this time, if the server's host controller does not support SG,
stub driver stores SG list in stub_priv->sgl (not in urb->sg) and
allocates URBs according to each entry of SG list. The page of each
SG list entry is mapped to each URB's transfer buffer.
(urb->transfer_buffer = sg_virt(sg))
So, when deallocating these URBs, stub driver doesn't deallocate the
URB's buffer with kfree(), but use sgl_free() to deallocate the SG
list stored
Re: High-Impact: xhci_hid - "Not enough bandwidth for new device state"
Hi! I just want to make the case that this is quite an important issue. I was very surprised to hear from the CIO of one of our customers that they had the same issue. This kept them from offering Ubuntu and an option for their Dell laptops. Like myself, these guys need to run GoToMeeting/WebEx together with a Windows VM for business. I understand this is probably a difficult bug and that it is difficult to reproduce. However, this combination of WebCam + VM is required by everybody except for a very few privileged "Linux only" developers. > It all depends on what that devices are asking for The Logitech C922 has a H.264 compression on the chip. The "bandwidth calculator" (https://www.google.es/search?q=H.264+bandwidth) says it needs 1024kBps for 1080p @ 30fps. Not sure if this is true, and I'm not sure what the devices actually does, though... > Linux solved Ok, so you have a clear idea what part of the driver causes the error, that's a step forward. But I can't imagine it's "real" bandwidth. USB 3.1 can handle two full-HD screens plus a Gigabit Ethernet on the same 5GBit lanes... A few megabit for compressed vido plus a few _kilo_ bits/s for audio... => Is there a way to debug these bandwidth requests for me? Maybe you want to include bandwidth requests in the kernel logs in the future if these issues are so wide spread? => Maybe you can recommend me a WebCam with tripod option that is known to work well with Linux? => From what I understand I should now test with VirtualBox and KVM/QEMU and check if the same issue appears. I will do this and let you know about the results. > configuration of your devices and root hubs I've got a brand new Dell XPX 15 9370 Laptop. No other USB hubs, devices, no change to any configuration. I chose the model because it is supposed to be the same that Linus Torvalds uses (well, XPS 13...) I can offer OpenVPN access to my laptop for reproducing the issues. I also offer to buy a Logitech C922 WebCam if somebody wants to get seriously down to this issue. Best Regards, Frank --- Frank Bergmann Dipl.-Ing., MBA Founder ]project-open[ Tel: +34 932 202 088 (Spain) Cell: +34 609 953 751 Fax: +34 932 890 729 mailto:frank.bergm...@project-open.com http://www.project-open.com http://www.twitter.com/projop http://www.facebook.com/projectopen.org http://www.linkedin.com/in/fraber http://www.xing.com/profile/Frank_Bergmann23
KASAN: use-after-free Read in device_release_driver_internal
Hello, syzbot found the following crash on: HEAD commit:6a3599ce usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=13f640cc60 kernel config: https://syzkaller.appspot.com/x/.config?x=700ca426ab83faae dashboard link: https://syzkaller.appspot.com/bug?extid=1b2449b7b5dc240d107a compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=116ce31fa0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1022f69460 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+1b2449b7b5dc240d1...@syzkaller.appspotmail.com usb 1-1: USB disconnect, device number 2 == BUG: KASAN: use-after-free in __lock_acquire+0x3a5d/0x5340 /kernel/locking/lockdep.c:3665 Read of size 8 at addr 8881cfc4ef90 by task kworker/0:2/108 CPU: 0 PID: 108 Comm: kworker/0:2 Not tainted 5.2.0-rc6+ #15 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack /lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e /lib/dump_stack.c:113 print_address_description+0x67/0x231 /mm/kasan/report.c:188 __kasan_report.cold+0x1a/0x32 /mm/kasan/report.c:317 kasan_report+0xe/0x20 /mm/kasan/common.c:614 __lock_acquire+0x3a5d/0x5340 /kernel/locking/lockdep.c:3665 lock_acquire+0x100/0x2b0 /kernel/locking/lockdep.c:4303 __mutex_lock_common /kernel/locking/mutex.c:926 [inline] __mutex_lock+0xf9/0x12b0 /kernel/locking/mutex.c:1073 device_release_driver_internal+0x23/0x4c0 /drivers/base/dd.c:1109 bus_remove_device+0x2dc/0x4a0 /drivers/base/bus.c:556 device_del+0x460/0xb80 /drivers/base/core.c:2274 usb_disable_device+0x211/0x690 /drivers/usb/core/message.c:1237 usb_disconnect+0x284/0x830 /drivers/usb/core/hub.c:2199 hub_port_connect /drivers/usb/core/hub.c:4949 [inline] hub_port_connect_change /drivers/usb/core/hub.c:5213 [inline] port_event /drivers/usb/core/hub.c:5359 [inline] hub_event+0x13bd/0x3550 /drivers/usb/core/hub.c:5441 process_one_work+0x905/0x1570 /kernel/workqueue.c:2269 worker_thread+0x96/0xe20 /kernel/workqueue.c:2415 kthread+0x30b/0x410 /kernel/kthread.c:255 ret_from_fork+0x24/0x30 /arch/x86/entry/entry_64.S:352 Allocated by task 88: save_stack+0x1b/0x80 /mm/kasan/common.c:71 set_track /mm/kasan/common.c:79 [inline] __kasan_kmalloc /mm/kasan/common.c:489 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 /mm/kasan/common.c:462 kmalloc /./include/linux/slab.h:547 [inline] kzalloc /./include/linux/slab.h:742 [inline] usb_set_configuration+0x2c4/0x1670 /drivers/usb/core/message.c:1846 generic_probe+0x9d/0xd5 /drivers/usb/core/generic.c:210 usb_probe_device+0x99/0x100 /drivers/usb/core/driver.c:266 really_probe+0x281/0x660 /drivers/base/dd.c:509 driver_probe_device+0x104/0x210 /drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 /drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 /drivers/base/bus.c:454 __device_attach+0x217/0x360 /drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 /drivers/base/bus.c:514 device_add+0xae6/0x16f0 /drivers/base/core.c:2111 usb_new_device.cold+0x6a4/0xe61 /drivers/usb/core/hub.c:2536 hub_port_connect /drivers/usb/core/hub.c:5098 [inline] hub_port_connect_change /drivers/usb/core/hub.c:5213 [inline] port_event /drivers/usb/core/hub.c:5359 [inline] hub_event+0x1abd/0x3550 /drivers/usb/core/hub.c:5441 process_one_work+0x905/0x1570 /kernel/workqueue.c:2269 worker_thread+0x96/0xe20 /kernel/workqueue.c:2415 kthread+0x30b/0x410 /kernel/kthread.c:255 ret_from_fork+0x24/0x30 /arch/x86/entry/entry_64.S:352 Freed by task 108: save_stack+0x1b/0x80 /mm/kasan/common.c:71 set_track /mm/kasan/common.c:79 [inline] __kasan_slab_free+0x130/0x180 /mm/kasan/common.c:451 slab_free_hook /mm/slub.c:1421 [inline] slab_free_freelist_hook /mm/slub.c:1448 [inline] slab_free /mm/slub.c:2994 [inline] kfree+0xd7/0x280 /mm/slub.c:3949 device_release+0x71/0x200 /drivers/base/core.c:1064 kobject_cleanup /lib/kobject.c:691 [inline] kobject_release /lib/kobject.c:720 [inline] kref_put /./include/linux/kref.h:65 [inline] kobject_put+0x171/0x280 /lib/kobject.c:737 put_device+0x1b/0x30 /drivers/base/core.c:2210 klist_put+0xce/0x170 /lib/klist.c:221 bus_remove_device+0x3a4/0x4a0 /drivers/base/bus.c:552 device_del+0x460/0xb80 /drivers/base/core.c:2274 usb_disable_device+0x211/0x690 /drivers/usb/core/message.c:1237 usb_disconnect+0x284/0x830 /drivers/usb/core/hub.c:2199 hub_port_connect /drivers/usb/core/hub.c:4949 [inline] hub_port_connect_change /drivers/usb/core/hub.c:5213 [inline] port_event /drivers/usb/core/hub.c:5359 [inline] hub_event+0x13bd/0x3550 /drivers/usb/core/hub.c:5441 process_one_work+0x905/0x1570 /kernel/workqueue.c:2269 worker_thread+0x96/0xe20 /kernel/workqueue.c:2415 kthread+0x30b/0x41
usb-fuzzer boot error: general protection fault in dma_direct_max_mapping_size
Hello, syzbot found the following crash on: HEAD commit:1154c0b0 wip git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=1197774c60 kernel config: https://syzkaller.appspot.com/x/.config?x=b228fb19779df17d dashboard link: https://syzkaller.appspot.com/bug?extid=4efacf59126f1ae87000 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+4efacf59126f1ae87...@syzkaller.appspotmail.com RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. pci :00:00.0: Limiting direct PCI/PCI transfers PCI: CLS 0 bytes, default 64 PCI-DMA: Using software bounce buffering for IO (SWIOTLB) software IO TLB: mapped [mem 0xbbffd000-0xbfffd000] (64MB) RAPL PMU: API unit is 2^-32 Joules, 0 fixed counters, 10737418240 ms ovfl timer clocksource: tsc: mask: 0x max_cycles: 0x212735223b2, max_idle_ns: 440795277976 ns clocksource: Switched to clocksource tsc check: Scanning for low memory corruption every 60 seconds Initialise system trusted keyrings workingset: timestamp_bits=40 max_order=21 bucket_order=0 NFS: Registering the id_resolver key type Key type id_resolver registered Key type id_legacy registered 9p: Installing v9fs 9p2000 file system support Key type asymmetric registered Asymmetric key parser 'x509' registered Block layer SCSI generic (bsg) driver version 0.4 loaded (major 247) io scheduler mq-deadline registered io scheduler kyber registered usbcore: registered new interface driver udlfb usbcore: registered new interface driver smscufx input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 ACPI: Power Button [PWRF] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1 ACPI: Sleep Button [SLPF] PCI Interrupt Link [LNKC] enabled at IRQ 11 virtio-pci :00:03.0: virtio_pci: leaving for legacy driver PCI Interrupt Link [LNKD] enabled at IRQ 10 virtio-pci :00:04.0: virtio_pci: leaving for legacy driver Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A 00:04: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A 00:05: ttyS2 at I/O 0x3e8 (irq = 6, base_baud = 115200) is a 16550A 00:06: ttyS3 at I/O 0x2e8 (irq = 7, base_baud = 115200) is a 16550A Non-volatile memory driver v1.3 Linux agpgart interface v0.103 usbcore: registered new interface driver udl loop: module loaded usbcore: registered new interface driver rtsx_usb usbcore: registered new interface driver viperboard usbcore: registered new interface driver dln2 usbcore: registered new interface driver pn533_usb usbcore: registered new interface driver port100 usbcore: registered new interface driver nfcmrvl scsi host0: Virtio SCSI HBA kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc1+ #16 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:dma_addressing_limited /./include/linux/dma-mapping.h:692 [inline] RIP: 0010:dma_direct_max_mapping_size+0x73/0x19a /kernel/dma/direct.c:408 Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 1e 01 00 00 48 8b 9d 38 03 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <80> 3c 02 00 0f 85 06 01 00 00 48 8d bd 48 03 00 00 48 8b 1b 48 b8 RSP: :8881da18f628 EFLAGS: 00010246 RAX: dc00 RBX: RCX: 812d716c RDX: RSI: 812d7189 RDI: 8881d7428378 RBP: 8881d7428040 R08: 8881da18 R09: ed103ade30cb R10: ed103ade30ca R11: 8881d6f18657 R12: 8881d7428040 R13: 8881d769e8b0 R14: 0200 R15: FS: () GS:8881db30() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 06a21000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: dma_max_mapping_size+0xb5/0xf0 /kernel/dma/mapping.c:375 __scsi_init_queue+0x17e/0x510 /drivers/scsi/scsi_lib.c:1787 scsi_mq_alloc_queue+0xcb/0x170 /drivers/scsi/scsi_lib.c:1833 scsi_alloc_sdev+0x82e/0xc50 /drivers/scsi/scsi_scan.c:269 scsi_probe_and_add_lun+0x1ee5/0x2cd0 /drivers/scsi/scsi_scan.c:1078 __scsi_scan_target+0x273/0xc30 /drivers/scsi/scsi_scan.c:1562 scsi_scan_channel.part.0+0x126/0x1a0 /drivers/scsi/scsi_scan.c:1650 scsi_scan_channel /drivers/scsi/scsi_scan.c:1677 [inline] scsi_scan_host_selected+0x2bb/0x3f0 /drivers/scsi/scsi_scan.c:1679 do_scsi_scan_host /drivers/scsi/scsi_scan.c:1817 [inline] do_scsi_scan_host+0x1e8/0x260 /
[PATCH] USB: serial: option: Add Motorola modem UARTs
On Motorola Mapphone devices such as Droid 4 there are five USB ports that do not use the same layout as Gobi 1K/2K/etc devices listed in qcserial.c. So we should use qcaux.c or option.c as noted by Dan Williams . As the Motorola USB serial ports have an interrupt endpoint as shown with lsusb -v, we should use option.c instead of qcaux.c as pointed out by Johan Hovold . The ff/ff/ff interfaces seem to always be UARTs on Motorola devices. For the other interfaces, class 0x0a (CDC Data) should not in general be added as they are typically part of a multi-interface function as noted earlier by Bjørn Mork . However, looking at the Motorola mapphone kernel code, the mdm6600 0x0a class is only used for flashing the modem firmware, and there are no other interfaces. So I've added that too with more details below as it works just fine. The ttyUSB ports on Droid 4 are: ttyUSB0 DIAG, CQDM-capable ttyUSB1 MUX or NMEA, no response ttyUSB2 MUX or NMEA, no response ttyUSB3 TCMD ttyUSB4 AT-capable The ttyUSB0 is detected as QCDM capable by ModemManager. I think it's only used for debugging with ModemManager --debug for sending custom AT commands though. ModemManager already can manage data connection using the USB QMI ports that are already handled by the qmi_wwan.c driver. To enable the MUX or NMEA ports, it seems that something needs to be done additionally to enable them, maybe via the DIAG or TCMD port. It might be just a NVRAM setting somewhere, but I have no idea what NVRAM settings may need changing for that. The TCMD port seems to be a Motorola custom protocol for testing the modem and to configure it's NVRAM and seems to work just fine based on a quick test with a minimal tcmdrw tool I wrote. The voice modem AT-capable port seems to provide only partial support, and no PM support compared to the TS 27.010 based UART wired directly to the modem. The UARTs added with this change are the same product IDs as the Motorola Mapphone Android Linux kernel mdm6600_id_table. I don't have any mdm9600 based devices, so I have only tested these on mdm6600 based droid 4. Then for the class 0x0a (CDC Data) mode, the Motorola Mapphone Android Linux kernel driver moto_flashqsc.c just seems to change the port->bulk_out_size to 8K from the default. And is only used for flashing the modem firmware it seems. I've verified that flashing the modem with signed firmware works just fine with the option driver after manually toggling the GPIO pins, so I've added droid 4 modem flashing mode to the option driver. I've not added the other devices listed in moto_flashqsc.c in case they really need different port->bulk_out_size. Those can be added as they get tested to work for flashing the modem. After this patch the output of /sys/kernel/debug/usb/devices has the following for normal 22b8:2a70 mode including the related qmi_wwan interfaces: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=22b8 ProdID=2a70 Rev= 0.00 S: Manufacturer=Motorola, Incorporated S: Product=Flash MZ600 C:* #Ifs= 9 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=5ms E: Ad=86(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=5ms E: Ad=88(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan E: Ad=89(I) Atr=03(Int.) MxPS= 64 Ivl=5ms E: Ad=8a(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 7 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan E: Ad=8b(I) Atr=03(Int.) MxPS= 64 Ivl=5ms E: Ad=8c(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=08(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan E: Ad=8d(I) Atr=03(Int.) MxPS= 64 Ivl=5ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=09(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms In 22b8:900e "qc_dload" mode the device shows up as: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=22b8 ProdID=900e Rev= 0.0
Re: High-Impact: xhci_hid - "Not enough bandwidth for new device state"
On Tue, 23 Jul 2019, Frank Bergmann wrote: > Hi! > > > I just want to make the case that this is quite an important issue. I > was very surprised to hear from the CIO of one of our customers that > they had the same issue. This kept them from offering Ubuntu and an > option for their Dell laptops. Like myself, these guys need to run > GoToMeeting/WebEx together with a Windows VM for business. > > > I understand this is probably a difficult bug and that it is difficult > to reproduce. However, this combination of WebCam + VM is required by > everybody except for a very few privileged "Linux only" developers. > > > > > It all depends on what that devices are asking for > > > The Logitech C922 has a H.264 compression on the chip. The "bandwidth > calculator" (https://www.google.es/search?q=H.264+bandwidth) says it > needs 1024kBps for 1080p @ 30fps. > > Not sure if this is true, and I'm not sure what the devices actually > does, though... > > > > Linux solved > > > Ok, so you have a clear idea what part of the driver causes the error, > that's a step forward. The situation is not as simple as you think. You're probably not aware of this, but with xHCI USB-3 controllers, bandwidth decisions are made by the hardware/firmware, not by the software. In particular, these decisions are not made by the kernel driver; they are made by the xHCI controller itself. Therefore changes to the kernel driver most likely cannot fix the problem. You would need to augment or replace your computer's xHCI USB-3 controller hardware. > But I can't imagine it's "real" bandwidth. USB 3.1 can handle two > full-HD screens plus a Gigabit Ethernet on the same 5GBit lanes... A few > megabit for compressed vido plus a few _kilo_ bits/s for audio... > > => Is there a way to debug these bandwidth requests for me? Maybe you > want to include bandwidth requests in the kernel logs in the future if > these issues are so wide spread? Here are some things you can do to provide more detailed debugging information. Unplug the webcam's USB cable, and then (as root) do: dmesg -C mount -t debugfs none /sys/kernel/debug echo 'module xhci_hcd =p' >/sys/kernel/debug/dynamic_debug/control echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable Plug in and try (and fail!) to use the webcam. Send output of dmesg Send contents of /sys/kernel/debug/usb/devices Send contents of /sys/kernel/debug/tracing/trace I won't be able to interpret all the results for you, but Mathias (the xhci-hcd maintainer) should be able to. However, you ought to realize in advance that the results are likely to show only that the hardware refused to allocate the necessary bandwidth and did not provide any explanation for its refusal. > => Maybe you can recommend me a WebCam with tripod option that is known > to work well with Linux? The issue may depend more on the type of xHCI controller than on the type of webcam. Alan Stern > => From what I understand I should now test with VirtualBox and KVM/QEMU > and check if the same issue appears. I will do this and let you know > about the results. > > > > configuration of your devices and root hubs > > > I've got a brand new Dell XPX 15 9370 Laptop. No other USB hubs, > devices, no change to any configuration. I chose the model because it is > supposed to be the same that Linus Torvalds uses (well, XPS 13...) > > > > I can offer OpenVPN access to my laptop for reproducing the issues. I > also offer to buy a Logitech C922 WebCam if somebody wants to get > seriously down to this issue. > > > Best Regards, > Frank > > --- > Frank Bergmann > Dipl.-Ing., MBA > Founder ]project-open[ > Tel: +34 932 202 088 (Spain) > Cell: +34 609 953 751 > Fax: +34 932 890 729 > > mailto:frank.bergm...@project-open.com > http://www.project-open.com > http://www.twitter.com/projop > http://www.facebook.com/projectopen.org > http://www.linkedin.com/in/fraber > http://www.xing.com/profile/Frank_Bergmann23
Re: [PATCH v3] usb-storage: Add a limitation for blk_queue_max_hw_sectors()
Looks good: Reviewed-by: Christoph Hellwig
Re: usb-fuzzer boot error: general protection fault in dma_direct_max_mapping_size
On Tue, Jul 23, 2019 at 07:48:05AM -0700, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:1154c0b0 wip > git tree: https://github.com/google/kasan.git usb-fuzzer > console output: https://syzkaller.appspot.com/x/log.txt?x=1197774c60 > kernel config: https://syzkaller.appspot.com/x/.config?x=b228fb19779df17d > dashboard link: https://syzkaller.appspot.com/bug?extid=4efacf59126f1ae87000 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+4efacf59126f1ae87...@syzkaller.appspotmail.com > > RPC: Registered udp transport module. > RPC: Registered tcp transport module. > RPC: Registered tcp NFSv4.1 backchannel transport module. > pci :00:00.0: Limiting direct PCI/PCI transfers > PCI: CLS 0 bytes, default 64 > PCI-DMA: Using software bounce buffering for IO (SWIOTLB) > software IO TLB: mapped [mem 0xbbffd000-0xbfffd000] (64MB) > RAPL PMU: API unit is 2^-32 Joules, 0 fixed counters, 10737418240 ms ovfl > timer > clocksource: tsc: mask: 0x max_cycles: 0x212735223b2, > max_idle_ns: 440795277976 ns > clocksource: Switched to clocksource tsc > check: Scanning for low memory corruption every 60 seconds > Initialise system trusted keyrings > workingset: timestamp_bits=40 max_order=21 bucket_order=0 > NFS: Registering the id_resolver key type > Key type id_resolver registered > Key type id_legacy registered > 9p: Installing v9fs 9p2000 file system support > Key type asymmetric registered > Asymmetric key parser 'x509' registered > Block layer SCSI generic (bsg) driver version 0.4 loaded (major 247) > io scheduler mq-deadline registered > io scheduler kyber registered > usbcore: registered new interface driver udlfb > usbcore: registered new interface driver smscufx > input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 > ACPI: Power Button [PWRF] > input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1 > ACPI: Sleep Button [SLPF] > PCI Interrupt Link [LNKC] enabled at IRQ 11 > virtio-pci :00:03.0: virtio_pci: leaving for legacy driver > PCI Interrupt Link [LNKD] enabled at IRQ 10 > virtio-pci :00:04.0: virtio_pci: leaving for legacy driver > Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A > 00:04: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A > 00:05: ttyS2 at I/O 0x3e8 (irq = 6, base_baud = 115200) is a 16550A > 00:06: ttyS3 at I/O 0x2e8 (irq = 7, base_baud = 115200) is a 16550A > Non-volatile memory driver v1.3 > Linux agpgart interface v0.103 > usbcore: registered new interface driver udl > loop: module loaded > usbcore: registered new interface driver rtsx_usb > usbcore: registered new interface driver viperboard > usbcore: registered new interface driver dln2 > usbcore: registered new interface driver pn533_usb > usbcore: registered new interface driver port100 > usbcore: registered new interface driver nfcmrvl > scsi host0: Virtio SCSI HBA > kasan: CONFIG_KASAN_INLINE enabled > kasan: GPF could be caused by NULL-ptr deref or user memory access > general protection fault: [#1] SMP KASAN > CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc1+ #16 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:dma_addressing_limited /./include/linux/dma-mapping.h:692 [inline] > RIP: 0010:dma_direct_max_mapping_size+0x73/0x19a /kernel/dma/direct.c:408 > Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 1e 01 00 00 48 8b 9d 38 03 > 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <80> 3c 02 00 0f 85 > 06 01 00 00 48 8d bd 48 03 00 00 48 8b 1b 48 b8 > RSP: :8881da18f628 EFLAGS: 00010246 > RAX: dc00 RBX: RCX: 812d716c > RDX: RSI: 812d7189 RDI: 8881d7428378 > RBP: 8881d7428040 R08: 8881da18 R09: ed103ade30cb > R10: ed103ade30ca R11: 8881d6f18657 R12: 8881d7428040 > R13: 8881d769e8b0 R14: 0200 R15: > FS: () GS:8881db30() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: CR3: 06a21000 CR4: 001406e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > dma_max_mapping_size+0xb5/0xf0 /kernel/dma/mapping.c:375 > __scsi_init_queue+0x17e/0x510 /drivers/scsi/scsi_lib.c:1787 > scsi_mq_alloc_queue+0xcb/0x170 /drivers/scsi/scsi_lib.c:1833 > scsi_alloc_sdev+0x82e/0xc50 /drivers/scsi/scsi_scan.c:269 > scsi_probe_and_add_lun+0x1ee5/0x2cd0 /drivers/scsi/scsi_scan.c:1078 > __scsi_scan_target+0x273/0xc30 /drivers/scsi/scsi_scan.c:1562 > scsi_scan_channel.part.0+0x126/0x1a0 /drivers/scsi/s
Re: usb-fuzzer boot error: general protection fault in dma_direct_max_mapping_size
On Tue, Jul 23, 2019 at 6:14 PM Eric Biggers wrote: > > On Tue, Jul 23, 2019 at 07:48:05AM -0700, syzbot wrote: > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit:1154c0b0 wip > > git tree: https://github.com/google/kasan.git usb-fuzzer > > console output: https://syzkaller.appspot.com/x/log.txt?x=1197774c60 > > kernel config: https://syzkaller.appspot.com/x/.config?x=b228fb19779df17d > > dashboard link: https://syzkaller.appspot.com/bug?extid=4efacf59126f1ae87000 > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > > Unfortunately, I don't have any reproducer for this crash yet. > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+4efacf59126f1ae87...@syzkaller.appspotmail.com > > > > RPC: Registered udp transport module. > > RPC: Registered tcp transport module. > > RPC: Registered tcp NFSv4.1 backchannel transport module. > > pci :00:00.0: Limiting direct PCI/PCI transfers > > PCI: CLS 0 bytes, default 64 > > PCI-DMA: Using software bounce buffering for IO (SWIOTLB) > > software IO TLB: mapped [mem 0xbbffd000-0xbfffd000] (64MB) > > RAPL PMU: API unit is 2^-32 Joules, 0 fixed counters, 10737418240 ms ovfl > > timer > > clocksource: tsc: mask: 0x max_cycles: 0x212735223b2, > > max_idle_ns: 440795277976 ns > > clocksource: Switched to clocksource tsc > > check: Scanning for low memory corruption every 60 seconds > > Initialise system trusted keyrings > > workingset: timestamp_bits=40 max_order=21 bucket_order=0 > > NFS: Registering the id_resolver key type > > Key type id_resolver registered > > Key type id_legacy registered > > 9p: Installing v9fs 9p2000 file system support > > Key type asymmetric registered > > Asymmetric key parser 'x509' registered > > Block layer SCSI generic (bsg) driver version 0.4 loaded (major 247) > > io scheduler mq-deadline registered > > io scheduler kyber registered > > usbcore: registered new interface driver udlfb > > usbcore: registered new interface driver smscufx > > input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 > > ACPI: Power Button [PWRF] > > input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1 > > ACPI: Sleep Button [SLPF] > > PCI Interrupt Link [LNKC] enabled at IRQ 11 > > virtio-pci :00:03.0: virtio_pci: leaving for legacy driver > > PCI Interrupt Link [LNKD] enabled at IRQ 10 > > virtio-pci :00:04.0: virtio_pci: leaving for legacy driver > > Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > > 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A > > 00:04: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A > > 00:05: ttyS2 at I/O 0x3e8 (irq = 6, base_baud = 115200) is a 16550A > > 00:06: ttyS3 at I/O 0x2e8 (irq = 7, base_baud = 115200) is a 16550A > > Non-volatile memory driver v1.3 > > Linux agpgart interface v0.103 > > usbcore: registered new interface driver udl > > loop: module loaded > > usbcore: registered new interface driver rtsx_usb > > usbcore: registered new interface driver viperboard > > usbcore: registered new interface driver dln2 > > usbcore: registered new interface driver pn533_usb > > usbcore: registered new interface driver port100 > > usbcore: registered new interface driver nfcmrvl > > scsi host0: Virtio SCSI HBA > > kasan: CONFIG_KASAN_INLINE enabled > > kasan: GPF could be caused by NULL-ptr deref or user memory access > > general protection fault: [#1] SMP KASAN > > CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc1+ #16 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > RIP: 0010:dma_addressing_limited /./include/linux/dma-mapping.h:692 [inline] > > RIP: 0010:dma_direct_max_mapping_size+0x73/0x19a /kernel/dma/direct.c:408 > > Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 1e 01 00 00 48 8b 9d 38 03 > > 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <80> 3c 02 00 0f 85 > > 06 01 00 00 48 8d bd 48 03 00 00 48 8b 1b 48 b8 > > RSP: :8881da18f628 EFLAGS: 00010246 > > RAX: dc00 RBX: RCX: 812d716c > > RDX: RSI: 812d7189 RDI: 8881d7428378 > > RBP: 8881d7428040 R08: 8881da18 R09: ed103ade30cb > > R10: ed103ade30ca R11: 8881d6f18657 R12: 8881d7428040 > > R13: 8881d769e8b0 R14: 0200 R15: > > FS: () GS:8881db30() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: CR3: 06a21000 CR4: 001406e0 > > DR0: DR1: DR2: > > DR3: DR6: fffe0ff0 DR7: 0400 > > Call Trace: > > dma_max_mapping_size+0xb5/0xf0 /kernel/dma/mapping.c:375 > > __scsi_init_queue+0x17e/0x510 /drivers/scsi/scsi_lib.c:1787 > > scsi_mq_alloc_queue+0xcb/0x170 /drivers/scsi/scsi_lib.c:1833 > > scsi_alloc_
Re: WARNING in snd_usb_motu_microbookii_communicate/usb_submit_urb
On Sat, Jul 20, 2019 at 4:14 PM Hillf Danton wrote: > > > On Fri, 19 Jul 2019 11:41:05 -0700 (PDT) > > syzbot has found a reproducer for the following crash on: > > > > HEAD commit:6a3599ce usb-fuzzer: main usb gadget fuzzer driver > > git tree: https://github.com/google/kasan.git usb-fuzzer > > console output: https://syzkaller.appspot.com/x/log.txt?x=149006d060 > > kernel config: https://syzkaller.appspot.com/x/.config?x=700ca426ab83faae > > dashboard link: https://syzkaller.appspot.com/bug?extid=d952e5e28f5fb7718d23 > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1710cd4860 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17650a3460 > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+d952e5e28f5fb7718...@syzkaller.appspotmail.com > > > > usb 1-1: string descriptor 0 read error: -22 > > usb 1-1: New USB device found, idVendor=07fd, idProduct=0004, > > bcdDevice=59.23 > > usb 1-1: New USB device strings: Mfr=5, Product=75, SerialNumber=0 > > usb 1-1: Waiting for MOTU Microbook II to boot up... > > [ cut here ] > > usb 1-1: BOGUS urb xfer, pipe 1 != type 3 > > WARNING: CPU: 1 PID: 21 at drivers/usb/core/urb.c:477 > > usb_submit_urb+0x1188/0x13b0 /drivers/usb/core/urb.c:477 > > Kernel panic - not syncing: panic_on_warn set ... > > CPU: 1 PID: 21 Comm: kworker/1:1 Not tainted 5.2.0-rc6+ #15 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > Workqueue: usb_hub_wq hub_event > > Call Trace: > > __dump_stack /lib/dump_stack.c:77 [inline] > > dump_stack+0xca/0x13e /lib/dump_stack.c:113 > > panic+0x292/0x6c9 /kernel/panic.c:219 > > __warn.cold+0x20/0x4b /kernel/panic.c:576 > > report_bug+0x262/0x2a0 /lib/bug.c:186 > > fixup_bug /arch/x86/kernel/traps.c:179 [inline] > > fixup_bug /arch/x86/kernel/traps.c:174 [inline] > > do_error_trap+0x12b/0x1e0 /arch/x86/kernel/traps.c:272 > > do_invalid_op+0x32/0x40 /arch/x86/kernel/traps.c:291 > > invalid_op+0x14/0x20 /arch/x86/entry/entry_64.S:986 > > RIP: 0010:usb_submit_urb+0x1188/0x13b0 /drivers/usb/core/urb.c:477 > > Code: 4d 85 ed 74 2c e8 f8 d3 f4 fd 4c 89 f7 e8 a0 51 1c ff 41 89 d8 44 89 > > e1 4c 89 ea 48 89 c6 48 c7 c7 00 0e f7 85 e8 83 98 ca fd <0f> 0b e9 20 f4 > > ff ff e8 cc d3 f4 fd 4c 89 f2 48 b8 00 00 00 00 00 > > RSP: 0018:8881d9efee68 EFLAGS: 00010286 > > RAX: RBX: 0003 RCX: > > RDX: RSI: 8127ef3d RDI: ed103b3dfdbf > > RBP: 8881cfd97b70 R08: 8881d9e36000 R09: > > R10: R11: R12: 0001 > > R13: 8881cfcdea98 R14: 8881d0f511a0 R15: 8881d4b46200 > > usb_start_wait_urb+0x108/0x2b0 /drivers/usb/core/message.c:57 > > usb_bulk_msg+0x228/0x550 /drivers/usb/core/message.c:253 > > snd_usb_motu_microbookii_communicate.constprop.0+0xe3/0x240 > > /sound/usb/quirks.c:999 > > snd_usb_motu_microbookii_boot_quirk /sound/usb/quirks.c:1039 [inline] > > snd_usb_apply_boot_quirk.cold+0x140/0x36b /sound/usb/quirks.c:1268 > > usb_audio_probe+0x2ec/0x2010 /sound/usb/card.c:576 > > usb_probe_interface+0x305/0x7a0 /drivers/usb/core/driver.c:361 > > really_probe+0x281/0x660 /drivers/base/dd.c:509 > > driver_probe_device+0x104/0x210 /drivers/base/dd.c:670 > > __device_attach_driver+0x1c2/0x220 /drivers/base/dd.c:777 > > bus_for_each_drv+0x15c/0x1e0 /drivers/base/bus.c:454 > > __device_attach+0x217/0x360 /drivers/base/dd.c:843 > > bus_probe_device+0x1e4/0x290 /drivers/base/bus.c:514 > > device_add+0xae6/0x16f0 /drivers/base/core.c:2111 > > usb_set_configuration+0xdf6/0x1670 /drivers/usb/core/message.c:2023 > > generic_probe+0x9d/0xd5 /drivers/usb/core/generic.c:210 > > usb_probe_device+0x99/0x100 /drivers/usb/core/driver.c:266 > > really_probe+0x281/0x660 /drivers/base/dd.c:509 > > driver_probe_device+0x104/0x210 /drivers/base/dd.c:670 > > __device_attach_driver+0x1c2/0x220 /drivers/base/dd.c:777 > > bus_for_each_drv+0x15c/0x1e0 /drivers/base/bus.c:454 > > __device_attach+0x217/0x360 /drivers/base/dd.c:843 > > bus_probe_device+0x1e4/0x290 /drivers/base/bus.c:514 > > device_add+0xae6/0x16f0 /drivers/base/core.c:2111 > > usb_new_device.cold+0x6a4/0xe61 /drivers/usb/core/hub.c:2536 > > hub_port_connect /drivers/usb/core/hub.c:5098 [inline] > > hub_port_connect_change /drivers/usb/core/hub.c:5213 [inline] > > port_event /drivers/usb/core/hub.c:5359 [inline] > > hub_event+0x1abd/0x3550 /drivers/usb/core/hub.c:5441 > > process_one_work+0x905/0x1570 /kernel/workqueue.c:2269 > > worker_thread+0x96/0xe20 /kernel/workqueue.c:2415 > > kthread+0x30b/0x410 /kernel/kthread.c:255 > > ret_from_fork+0x24/0x30 /arch/x86/entry/entry_64.S:352 > > Kernel Offset: disabled > > Rebooting in 86400 seconds.. > > Wow it finally comes
WARNING in kbtab_open/usb_submit_urb
Hello, syzbot found the following crash on: HEAD commit:6a3599ce usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=1033419460 kernel config: https://syzkaller.appspot.com/x/.config?x=700ca426ab83faae dashboard link: https://syzkaller.appspot.com/bug?extid=c7df50363aaff50aa363 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17309e9460 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1092935860 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c7df50363aaff50aa...@syzkaller.appspotmail.com [ cut here ] usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 1732 at drivers/usb/core/urb.c:477 usb_submit_urb+0x1188/0x13b0 /drivers/usb/core/urb.c:477 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 1732 Comm: syz-executor835 Not tainted 5.2.0-rc6+ #15 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack /lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e /lib/dump_stack.c:113 panic+0x292/0x6c9 /kernel/panic.c:219 __warn.cold+0x20/0x4b /kernel/panic.c:576 report_bug+0x262/0x2a0 /lib/bug.c:186 fixup_bug /arch/x86/kernel/traps.c:179 [inline] fixup_bug /arch/x86/kernel/traps.c:174 [inline] do_error_trap+0x12b/0x1e0 /arch/x86/kernel/traps.c:272 do_invalid_op+0x32/0x40 /arch/x86/kernel/traps.c:291 invalid_op+0x14/0x20 /arch/x86/entry/entry_64.S:986 RIP: 0010:usb_submit_urb+0x1188/0x13b0 /drivers/usb/core/urb.c:477 Code: 4d 85 ed 74 2c e8 f8 d3 f4 fd 4c 89 f7 e8 a0 51 1c ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 00 0e f7 85 e8 83 98 ca fd <0f> 0b e9 20 f4 ff ff e8 cc d3 f4 fd 4c 89 f2 48 b8 00 00 00 00 00 RSP: 0018:8881d06bf878 EFLAGS: 00010282 RAX: RBX: 0003 RCX: RDX: RSI: 8127ef3d RDI: ed103a0d7f01 RBP: 8881d0bf5500 R08: 8881d2678000 R09: R10: R11: R12: 0001 R13: 8881d40b58a0 R14: 8881d0904d20 R15: 8881d3cd9900 kbtab_open+0xd5/0x130 /drivers/input/tablet/kbtab.c:96 input_open_device+0x170/0x280 /drivers/input/input.c:607 evdev_open_device /drivers/input/evdev.c:433 [inline] evdev_open+0x3fe/0x510 /drivers/input/evdev.c:518 chrdev_open+0x219/0x5c0 /fs/char_dev.c:413 do_dentry_open+0x497/0x1040 /fs/open.c:778 do_last /fs/namei.c:3416 [inline] path_openat+0x1430/0x3ff0 /fs/namei.c:3533 do_filp_open+0x1a1/0x280 /fs/namei.c:3563 do_sys_open+0x3c0/0x580 /fs/open.c:1070 do_syscall_64+0xb7/0x560 /arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4010c0 Code: 01 f0 ff ff 0f 83 00 0b 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 83 3d cd 4c 2d 00 00 75 14 b8 02 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 d4 0a 00 00 c3 48 83 ec 08 e8 3a 00 00 00 RSP: 002b:7ffd69a61888 EFLAGS: 0246 ORIG_RAX: 0002 RAX: ffda RBX: RCX: 004010c0 RDX: RSI: RDI: 7ffd69a61890 RBP: 6667 R08: 000f R09: 000b R10: 0075 R11: 0246 R12: 00402020 R13: 004020b0 R14: R15: Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH v3] usb: dwc3: gadget: trb_dequeue is not updated properly
On Thu, Jul 18, 2019 at 6:12 PM Thinh Nguyen wrote:
> fei.y...@intel.com wrote:
> > From: Fei Yang
> >
> > If scatter-gather operation is allowed, a large USB request is split into
> > multiple TRBs. These TRBs are chained up by setting DWC3_TRB_CTRL_CHN bit
> > except the last one which has DWC3_TRB_CTRL_IOC bit set instead.
> > Since only the last TRB has IOC set for the whole USB request, the
> > dwc3_gadget_ep_reclaim_trb_sg() gets called only once after the last TRB
> > completes and all the TRBs allocated for this request are supposed to be
> > reclaimed. However that is not what the current code does.
> >
> > dwc3_gadget_ep_reclaim_trb_sg() is trying to reclaim all the TRBs in the
> > following for-loop,
> > for_each_sg(sg, s, pending, i) {
> > trb = &dep->trb_pool[dep->trb_dequeue];
> >
> > if (trb->ctrl & DWC3_TRB_CTRL_HWO)
> > break;
> >
> > req->sg = sg_next(s);
> > req->num_pending_sgs--;
> >
> > ret = dwc3_gadget_ep_reclaim_completed_trb(dep, req,
> > trb, event, status, chain);
> > if (ret)
> > break;
> > }
> > but since the interrupt comes only after the last TRB completes, the
> > event->status has DEPEVT_STATUS_IOC bit set, so that the for-loop ends for
> > the first TRB due to dwc3_gadget_ep_reclaim_completed_trb() returns 1.
> > if (event->status & DEPEVT_STATUS_IOC)
> > return 1;
> >
> > This patch addresses the issue by checking each TRB in function
> > dwc3_gadget_ep_reclaim_trb_sg() and maing sure the chained ones are properly
> > reclaimed. dwc3_gadget_ep_reclaim_completed_trb() will return 1 Only for the
> > last TRB.
> >
> > Signed-off-by: Fei Yang
> > Cc: stable
> > ---
> > v2: Better solution is to reclaim chained TRBs in
> > dwc3_gadget_ep_reclaim_trb_sg()
> > and leave the last TRB to the dwc3_gadget_ep_reclaim_completed_trb().
> > v3: Checking DWC3_TRB_CTRL_CHN bit for each TRB instead, and making sure
> > that
> > dwc3_gadget_ep_reclaim_completed_trb() returns 1 only for the last TRB.
> > ---
> > drivers/usb/dwc3/gadget.c | 11 ---
> > 1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> > index 173f532..88eed49 100644
> > --- a/drivers/usb/dwc3/gadget.c
> > +++ b/drivers/usb/dwc3/gadget.c
> > @@ -2394,7 +2394,7 @@ static int
> > dwc3_gadget_ep_reclaim_completed_trb(struct dwc3_ep *dep,
> > if (event->status & DEPEVT_STATUS_SHORT && !chain)
> > return 1;
> >
> > - if (event->status & DEPEVT_STATUS_IOC)
> > + if (event->status & DEPEVT_STATUS_IOC && !chain)
> > return 1;
> >
> > return 0;
> > @@ -2404,11 +2404,12 @@ static int dwc3_gadget_ep_reclaim_trb_sg(struct
> > dwc3_ep *dep,
> > struct dwc3_request *req, const struct dwc3_event_depevt
> > *event,
> > int status)
> > {
> > - struct dwc3_trb *trb = &dep->trb_pool[dep->trb_dequeue];
> > + struct dwc3_trb *trb;
> > struct scatterlist *sg = req->sg;
> > struct scatterlist *s;
> > unsigned int pending = req->num_pending_sgs;
> > unsigned int i;
> > + int chain = false;
> > int ret = 0;
> >
> > for_each_sg(sg, s, pending, i) {
> > @@ -2419,9 +2420,13 @@ static int dwc3_gadget_ep_reclaim_trb_sg(struct
> > dwc3_ep *dep,
> >
> > req->sg = sg_next(s);
> > req->num_pending_sgs--;
> > + if (trb->ctrl & DWC3_TRB_CTRL_CHN)
> > + chain = true;
> > + else
> > + chain = false;
> >
> > ret = dwc3_gadget_ep_reclaim_completed_trb(dep, req,
> > - trb, event, status, true);
> > + trb, event, status, chain);
> > if (ret)
> > break;
> > }
>
> There was already a fix a long time ago by Anurag. But it never made it
> to the kernel mainline. You can check this out:
> https://patchwork.kernel.org/patch/10640137/
So, back from a vacation last week, and just validated that both Fei's
patch and a forward ported version of this patch Thinh pointed out
both seem to resolve the usb stalls I've been seeing sinice 4.20 w/
dwc3 hardware on both hikey960 and dragonboard 845c.
Felipe: Does Anurag's patch above make more sense as a proper fix?
thanks
-john
RE: [PATCH v3] usb: dwc3: gadget: trb_dequeue is not updated properly
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c >> index 173f532..88eed49 100644 >> --- a/drivers/usb/dwc3/gadget.c >> +++ b/drivers/usb/dwc3/gadget.c >> @@ -2394,7 +2394,7 @@ static int dwc3_gadget_ep_reclaim_completed_trb(struct >> dwc3_ep *dep, >> if (event->status & DEPEVT_STATUS_SHORT && !chain) >> return 1; >> >> -if (event->status & DEPEVT_STATUS_IOC) >> +if (event->status & DEPEVT_STATUS_IOC && !chain) >> return 1; > > This will break the situation when we have more SGs than available TRBs. In > that case we set IOC before the last so we have time to update transfer to > append more TRBs. What's your opinion on https://patchwork.kernel.org/patch/10640137/? Checking condition "(event->status & DEPEVT_STATUS_IOC) && (trb->ctrl & DWC3_TRB_CTRL_IOC)" won't cause problem handling TRB shortage cases, right? > Please, send me tracepoints I sent you the tracepoints last Friday, any new findings?
[PATCH v1] usb: dwc2: Switch to use device_property_count_u32()
Use use device_property_count_u32() directly, that makes code neater.
Signed-off-by: Andy Shevchenko
---
drivers/usb/dwc2/params.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 55f841a54015..31e090ac9f1e 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -404,10 +404,7 @@ static void dwc2_get_device_properties(struct dwc2_hsotg
*hsotg)
device_property_read_u32(hsotg->dev, "g-np-tx-fifo-size",
&p->g_np_tx_fifo_size);
- num = device_property_read_u32_array(hsotg->dev,
-"g-tx-fifo-size",
-NULL, 0);
-
+ num = device_property_count_u32(hsotg->dev, "g-tx-fifo-size");
if (num > 0) {
num = min(num, 15);
memset(p->g_tx_fifo_size, 0,
--
2.20.1
[PATCH v1] usb: dwc3: Switch to use device_property_count_u32()
Use use device_property_count_u32() directly, that makes code neater. Signed-off-by: Andy Shevchenko --- drivers/usb/dwc3/core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index c9bb93a2c81e..98bce85c29d0 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -813,8 +813,7 @@ static void dwc3_set_incr_burst_type(struct dwc3 *dwc) * result = 1, means INCRx burst mode supported. * result > 1, means undefined length burst mode supported. */ - ntype = device_property_read_u32_array(dev, - "snps,incr-burst-type-adjustment", NULL, 0); + ntype = device_property_count_u32(dev, "snps,incr-burst-type-adjustment"); if (ntype <= 0) return; -- 2.20.1
[PATCH v1] usb: typec: tcpm: Switch to use fwnode_property_count_uXX()
Use use fwnode_property_count_uXX() directly, that makes code neater. Signed-off-by: Andy Shevchenko --- drivers/usb/typec/tcpm/tcpm.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index fba32d84e578..ec525811a9eb 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -4410,8 +4410,7 @@ static int tcpm_fw_get_caps(struct tcpm_port *port, goto sink; /* Get source pdos */ - ret = fwnode_property_read_u32_array(fwnode, "source-pdos", -NULL, 0); + ret = fwnode_property_count_u32(fwnode, "source-pdos"); if (ret <= 0) return -EINVAL; @@ -4435,8 +4434,7 @@ static int tcpm_fw_get_caps(struct tcpm_port *port, return -EINVAL; sink: /* Get sink pdos */ - ret = fwnode_property_read_u32_array(fwnode, "sink-pdos", -NULL, 0); + ret = fwnode_property_count_u32(fwnode, "sink-pdos"); if (ret <= 0) return -EINVAL; -- 2.20.1
[PATCH v1] usb: typec: mux: Switch to use fwnode_property_count_uXX()
Use fwnode_property_count_uXX() directly, that makes code neater. Signed-off-by: Andy Shevchenko --- drivers/usb/typec/mux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/typec/mux.c b/drivers/usb/typec/mux.c index 61b7bc58dd81..57907f26f681 100644 --- a/drivers/usb/typec/mux.c +++ b/drivers/usb/typec/mux.c @@ -215,7 +215,7 @@ static void *typec_mux_match(struct device_connection *con, int ep, void *data) } /* Alternate Mode muxes */ - nval = fwnode_property_read_u16_array(con->fwnode, "svid", NULL, 0); + nval = fwnode_property_count_u16(con->fwnode, "svid"); if (nval <= 0) return NULL; -- 2.20.1
Re: [PATCH v1] usb: typec: tcpm: Switch to use fwnode_property_count_uXX()
On Tue, Jul 23, 2019 at 10:37:50PM +0300, Andy Shevchenko wrote: > Use use fwnode_property_count_uXX() directly, that makes code neater. > > Signed-off-by: Andy Shevchenko Reviewed-by: Guenter Roeck > --- > drivers/usb/typec/tcpm/tcpm.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c > index fba32d84e578..ec525811a9eb 100644 > --- a/drivers/usb/typec/tcpm/tcpm.c > +++ b/drivers/usb/typec/tcpm/tcpm.c > @@ -4410,8 +4410,7 @@ static int tcpm_fw_get_caps(struct tcpm_port *port, > goto sink; > > /* Get source pdos */ > - ret = fwnode_property_read_u32_array(fwnode, "source-pdos", > - NULL, 0); > + ret = fwnode_property_count_u32(fwnode, "source-pdos"); > if (ret <= 0) > return -EINVAL; > > @@ -4435,8 +4434,7 @@ static int tcpm_fw_get_caps(struct tcpm_port *port, > return -EINVAL; > sink: > /* Get sink pdos */ > - ret = fwnode_property_read_u32_array(fwnode, "sink-pdos", > - NULL, 0); > + ret = fwnode_property_count_u32(fwnode, "sink-pdos"); > if (ret <= 0) > return -EINVAL; > > -- > 2.20.1 >
[PATCH] usb: dwc3: Check for IOC/LST bit in both event->status and TRB->ctrl fields
From: Anurag Kumar Vulisha The present code in dwc3_gadget_ep_reclaim_completed_trb() will check for IOC/LST bit in the event->status and returns if IOC/LST bit is set. This logic doesn't work if multiple TRBs are queued per request and the IOC/LST bit is set on the last TRB of that request. Consider an example where a queued request has multiple queued TRBs and IOC/LST bit is set only for the last TRB. In this case, the Core generates XferComplete/XferInProgress events only for the last TRB (since IOC/LST are set only for the last TRB). As per the logic in dwc3_gadget_ep_reclaim_completed_trb() event->status is checked for IOC/LST bit and returns on the first TRB. This makes the remaining TRBs left unhandled. To aviod this, changed the code to check for IOC/LST bits in both event->status & TRB->ctrl. This patch does the same. At a practical level, this patch resolves USB transfer stalls seen with adb on dwc3 based Android devices after functionfs gadget added scatter-gather support around v4.20. Cc: Felipe Balbi Cc: Fei Yang Cc: Thinh Nguyen Cc: Tejas Joglekar Cc: Andrzej Pietrasiewicz Cc: Greg KH Cc: Linux USB List Cc: stable Tested-By: Tejas Joglekar Reviewed-by: Thinh Nguyen Signed-off-by: Anurag Kumar Vulisha [jstultz: forward ported to mainline, added note to commit log] Signed-off-by: John Stultz --- Just wanted to send this out so we're all looking at the same thing. Not sure if its correct, but it seems to solve the adb stalls I've been seeing for awhile. thanks -john drivers/usb/dwc3/gadget.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index c9cecb3a9670..1d9701dde69b 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -2394,7 +2394,12 @@ static int dwc3_gadget_ep_reclaim_completed_trb(struct dwc3_ep *dep, if (event->status & DEPEVT_STATUS_SHORT && !chain) return 1; - if (event->status & DEPEVT_STATUS_IOC) + if ((event->status & DEPEVT_STATUS_IOC) && + (trb->ctrl & DWC3_TRB_CTRL_IOC)) + return 1; + + if ((event->status & DEPEVT_STATUS_LST) && + (trb->ctrl & DWC3_TRB_CTRL_LST)) return 1; return 0; -- 2.17.1
[PATCH v3 1/7] drivers: Introduce device lookup variants by name
Add a helper to match the device name for device lookup. Also
reuse this generic exported helper for the existing bus_find_device_by_name().
and add similar variants for driver/class.
Cc: Alessandro Zummo
Cc: Alexander Aring
Cc: Alexander Shishkin
Cc: Alexandre Belloni
Cc: Arnd Bergmann
Cc: Dan Murphy
Cc: Greg Kroah-Hartman
Cc: Harald Freudenberger
Cc: Heikki Krogerus
Cc: Heiko Carstens
Cc: Jacek Anaszewski
Cc: Lee Jones
Cc: linux-l...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-w...@vger.kernel.org
Cc: Maxime Coquelin
Cc: Pavel Machek
Cc: Peter Oberparleiter
Cc: "Rafael J. Wysocki"
Cc: Stefan Schmidt
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Signed-off-by: Suzuki K Poulose
---
drivers/base/bus.c | 24 --
drivers/base/core.c | 6 +
drivers/hwtracing/stm/core.c | 9 +--
drivers/leds/led-class.c | 9 +--
drivers/rtc/interface.c | 11 +
drivers/s390/cio/ccwgroup.c | 10 +---
drivers/s390/cio/device.c| 15 +---
drivers/s390/crypto/zcrypt_api.c | 11 +
drivers/usb/roles/class.c| 8 +-
drivers/usb/typec/class.c| 8 +-
include/linux/device.h | 42 +---
net/ieee802154/core.c| 7 +-
12 files changed, 54 insertions(+), 106 deletions(-)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index df3cac739813..a1d1e8256324 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -342,30 +342,6 @@ struct device *bus_find_device(struct bus_type *bus,
}
EXPORT_SYMBOL_GPL(bus_find_device);
-static int match_name(struct device *dev, const void *data)
-{
- const char *name = data;
-
- return sysfs_streq(name, dev_name(dev));
-}
-
-/**
- * bus_find_device_by_name - device iterator for locating a particular device
of a specific name
- * @bus: bus type
- * @start: Device to begin with
- * @name: name of the device to match
- *
- * This is similar to the bus_find_device() function above, but it handles
- * searching by a name automatically, no need to write another strcmp matching
- * function.
- */
-struct device *bus_find_device_by_name(struct bus_type *bus,
- struct device *start, const char *name)
-{
- return bus_find_device(bus, start, (void *)name, match_name);
-}
-EXPORT_SYMBOL_GPL(bus_find_device_by_name);
-
/**
* subsys_find_device_by_id - find a device with a specific enumeration number
* @subsys: subsystem
diff --git a/drivers/base/core.c b/drivers/base/core.c
index da84a73f2ba6..fb83647d685a 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3357,6 +3357,12 @@ void device_set_of_node_from_dev(struct device *dev,
const struct device *dev2)
}
EXPORT_SYMBOL_GPL(device_set_of_node_from_dev);
+int device_match_name(struct device *dev, const void *name)
+{
+ return sysfs_streq(dev_name(dev), name);
+}
+EXPORT_SYMBOL_GPL(device_match_name);
+
int device_match_of_node(struct device *dev, const void *np)
{
return dev->of_node == np;
diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index e55b902560de..2b6bd42632e8 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -89,13 +89,6 @@ static struct class stm_class = {
.dev_groups = stm_groups,
};
-static int stm_dev_match(struct device *dev, const void *data)
-{
- const char *name = data;
-
- return sysfs_streq(name, dev_name(dev));
-}
-
/**
* stm_find_device() - find stm device by name
* @buf: character buffer containing the name
@@ -116,7 +109,7 @@ struct stm_device *stm_find_device(const char *buf)
if (!stm_core_up)
return NULL;
- dev = class_find_device(&stm_class, NULL, buf, stm_dev_match);
+ dev = class_find_device_by_name(&stm_class, buf);
if (!dev)
return NULL;
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 4793e77808e2..d54c8e4d8954 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -213,13 +213,6 @@ static int led_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(leds_class_dev_pm_ops, led_suspend, led_resume);
-static int match_name(struct device *dev, const void *data)
-{
- if (!dev_name(dev))
- return 0;
- return !strcmp(dev_name(dev), (char *)data);
-}
-
static int led_classdev_next_name(const char *init_name, char *name,
size_t len)
{
@@ -230,7 +223,7 @@ static int led_classdev_next_name(const char *init_name,
char *name,
strlcpy(name, init_name, len);
while ((ret < len) &&
- (dev = class_find_device(leds_class, NULL, name, match_name))) {
+ (dev = class_find_device_by_name(leds_class, name))) {
put_device(dev);
ret = snprintf(name, len, "%s_%u", init_name, ++i);
[PATCH v3 4/7] drivers: Introduce device lookup variants by device type
Add a helper to match a device by its type and provide wrappers
for {bus/class/driver}_find_device() APIs.
Cc: Alexander Shishkin
Cc: Arnd Bergmann
Cc: Harald Freudenberger
Cc: Heiko Carstens
Cc: linux-usb@vger.kernel.org
Cc: Oliver Neukum
Cc: Sebastian Andrzej Siewior
Cc: Tomas Winkler
Cc: "Rafael J. Wysocki"
Cc: Greg Kroah-Hartman
Cc: Ulf Hansson
Cc: Joe Perches
Signed-off-by: Suzuki K Poulose
---
drivers/base/core.c | 15 ++---
drivers/hwtracing/intel_th/core.c | 10 +
drivers/misc/mei/main.c | 9 +---
drivers/s390/crypto/zcrypt_api.c | 11 +
drivers/tty/tty_io.c | 8 +--
drivers/usb/core/devio.c | 8 +--
include/linux/device.h| 37 +++
7 files changed, 49 insertions(+), 49 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index e8f81a667545..3abc32b60c0a 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2867,13 +2867,6 @@ struct device *device_create_with_groups(struct class
*class,
}
EXPORT_SYMBOL_GPL(device_create_with_groups);
-static int __match_devt(struct device *dev, const void *data)
-{
- const dev_t *devt = data;
-
- return dev->devt == *devt;
-}
-
/**
* device_destroy - removes a device that was created with device_create()
* @class: pointer to the struct class that this device was registered with
@@ -2886,7 +2879,7 @@ void device_destroy(struct class *class, dev_t devt)
{
struct device *dev;
- dev = class_find_device(class, NULL, &devt, __match_devt);
+ dev = class_find_device_by_devt(class, devt);
if (dev) {
put_device(dev);
device_unregister(dev);
@@ -3374,3 +3367,9 @@ int device_match_fwnode(struct device *dev, const void
*fwnode)
return dev_fwnode(dev) == fwnode;
}
EXPORT_SYMBOL_GPL(device_match_fwnode);
+
+int device_match_devt(struct device *dev, const void *pdevt)
+{
+ return dev->devt == *(dev_t *)pdevt;
+}
+EXPORT_SYMBOL_GPL(device_match_devt);
diff --git a/drivers/hwtracing/intel_th/core.c
b/drivers/hwtracing/intel_th/core.c
index 55922896d862..d5c1821b31c6 100644
--- a/drivers/hwtracing/intel_th/core.c
+++ b/drivers/hwtracing/intel_th/core.c
@@ -789,12 +789,6 @@ static int intel_th_populate(struct intel_th *th)
return 0;
}
-static int match_devt(struct device *dev, const void *data)
-{
- dev_t devt = (dev_t)(unsigned long)(void *)data;
- return dev->devt == devt;
-}
-
static int intel_th_output_open(struct inode *inode, struct file *file)
{
const struct file_operations *fops;
@@ -802,9 +796,7 @@ static int intel_th_output_open(struct inode *inode, struct
file *file)
struct device *dev;
int err;
- dev = bus_find_device(&intel_th_bus, NULL,
- (void *)(unsigned long)inode->i_rdev,
- match_devt);
+ dev = bus_find_device_by_devt(&intel_th_bus, inode->i_rdev);
if (!dev || !dev->driver)
return -ENODEV;
diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c
index f894d1f8a53e..7310b476323c 100644
--- a/drivers/misc/mei/main.c
+++ b/drivers/misc/mei/main.c
@@ -858,13 +858,6 @@ static ssize_t dev_state_show(struct device *device,
}
static DEVICE_ATTR_RO(dev_state);
-static int match_devt(struct device *dev, const void *data)
-{
- const dev_t *devt = data;
-
- return dev->devt == *devt;
-}
-
/**
* dev_set_devstate: set to new device state and notify sysfs file.
*
@@ -880,7 +873,7 @@ void mei_set_devstate(struct mei_device *dev, enum
mei_dev_state state)
dev->dev_state = state;
- clsdev = class_find_device(mei_class, NULL, &dev->cdev.dev, match_devt);
+ clsdev = class_find_device_by_devt(mei_class, dev->cdev.dev);
if (clsdev) {
sysfs_notify(&clsdev->kobj, NULL, "dev_state");
put_device(clsdev);
diff --git a/drivers/s390/crypto/zcrypt_api.c b/drivers/s390/crypto/zcrypt_api.c
index 38a5a47b8c9c..150f6236c9bb 100644
--- a/drivers/s390/crypto/zcrypt_api.c
+++ b/drivers/s390/crypto/zcrypt_api.c
@@ -133,12 +133,6 @@ struct zcdn_device {
static int zcdn_create(const char *name);
static int zcdn_destroy(const char *name);
-/* helper function, matches the devt value for find_zcdndev_by_devt() */
-static int __match_zcdn_devt(struct device *dev, const void *data)
-{
- return dev->devt == *((dev_t *) data);
-}
-
/*
* Find zcdn device by name.
* Returns reference to the zcdn device which needs to be released
@@ -158,10 +152,7 @@ static inline struct zcdn_device
*find_zcdndev_by_name(const char *name)
*/
static inline struct zcdn_device *find_zcdndev_by_devt(dev_t devt)
{
- struct device *dev =
- class_find_device(zcrypt_class, NULL,
- (void *) &devt,
- __match_zcdn_devt);
+ struct device *de
[PATCH v3 3/7] drivers: Introduce device lookup variants by fwnode
Add a helper to match the firmware node handle of a device and provide
wrappers for {bus/class/driver}_find_device() APIs to avoid proliferation
of duplicate custom match functions.
Cc: "David S. Miller"
Cc: Doug Ledford
Cc: Greg Kroah-Hartman
Cc: Heikki Krogerus
Cc: Jason Gunthorpe
Cc: linux-usb@vger.kernel.org
Cc: "Rafael J. Wysocki"
Cc: Greg Kroah-Hartman
Cc: Ulf Hansson
Cc: Joe Perches
Cc: Mathieu Poirier
Cc: Will Deacon
Cc: Robin Murphy
Cc: Joerg Roedel
Signed-off-by: Suzuki K Poulose
---
drivers/base/core.c | 6 +++
drivers/base/devcon.c | 8 +---
.../hwtracing/coresight/coresight-platform.c | 11 +-
drivers/hwtracing/coresight/coresight-priv.h | 2 -
drivers/hwtracing/coresight/coresight.c | 4 +-
drivers/infiniband/hw/hns/hns_roce_hw_v1.c| 8 +---
drivers/iommu/arm-smmu-v3.c | 9 +
drivers/iommu/arm-smmu.c | 9 +
.../ethernet/hisilicon/hns/hns_dsaf_misc.c| 8 +---
drivers/usb/roles/class.c | 8 +---
drivers/usb/typec/class.c | 8 +---
include/linux/device.h| 39 +++
12 files changed, 57 insertions(+), 63 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index fb83647d685a..e8f81a667545 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3368,3 +3368,9 @@ int device_match_of_node(struct device *dev, const void
*np)
return dev->of_node == np;
}
EXPORT_SYMBOL_GPL(device_match_of_node);
+
+int device_match_fwnode(struct device *dev, const void *fwnode)
+{
+ return dev_fwnode(dev) == fwnode;
+}
+EXPORT_SYMBOL_GPL(device_match_fwnode);
diff --git a/drivers/base/devcon.c b/drivers/base/devcon.c
index 09f28479b243..1d488dc5dd0c 100644
--- a/drivers/base/devcon.c
+++ b/drivers/base/devcon.c
@@ -133,19 +133,13 @@ static struct bus_type *generic_match_buses[] = {
NULL,
};
-static int device_fwnode_match(struct device *dev, const void *fwnode)
-{
- return dev_fwnode(dev) == fwnode;
-}
-
static void *device_connection_fwnode_match(struct device_connection *con)
{
struct bus_type *bus;
struct device *dev;
for (bus = generic_match_buses[0]; bus; bus++) {
- dev = bus_find_device(bus, NULL, (void *)con->fwnode,
- device_fwnode_match);
+ dev = bus_find_device_by_fwnode(bus, con->fwnode);
if (dev && !strncmp(dev_name(dev), con->id, strlen(con->id)))
return dev;
diff --git a/drivers/hwtracing/coresight/coresight-platform.c
b/drivers/hwtracing/coresight/coresight-platform.c
index dad7d96c5943..3c5bee429105 100644
--- a/drivers/hwtracing/coresight/coresight-platform.c
+++ b/drivers/hwtracing/coresight/coresight-platform.c
@@ -37,11 +37,6 @@ static int coresight_alloc_conns(struct device *dev,
return 0;
}
-int coresight_device_fwnode_match(struct device *dev, const void *fwnode)
-{
- return dev_fwnode(dev) == fwnode;
-}
-
static struct device *
coresight_find_device_by_fwnode(struct fwnode_handle *fwnode)
{
@@ -51,8 +46,7 @@ coresight_find_device_by_fwnode(struct fwnode_handle *fwnode)
* If we have a non-configurable replicator, it will be found on the
* platform bus.
*/
- dev = bus_find_device(&platform_bus_type, NULL,
- fwnode, coresight_device_fwnode_match);
+ dev = bus_find_device_by_fwnode(&platform_bus_type, fwnode);
if (dev)
return dev;
@@ -60,8 +54,7 @@ coresight_find_device_by_fwnode(struct fwnode_handle *fwnode)
* We have a configurable component - circle through the AMBA bus
* looking for the device that matches the endpoint node.
*/
- return bus_find_device(&amba_bustype, NULL,
- fwnode, coresight_device_fwnode_match);
+ return bus_find_device_by_fwnode(&amba_bustype, fwnode);
}
#ifdef CONFIG_OF
diff --git a/drivers/hwtracing/coresight/coresight-priv.h
b/drivers/hwtracing/coresight/coresight-priv.h
index 7d401790dd7e..61d7f9ff054d 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -202,6 +202,4 @@ static inline void *coresight_get_uci_data(const struct
amba_id *id)
void coresight_release_platform_data(struct coresight_platform_data *pdata);
-int coresight_device_fwnode_match(struct device *dev, const void *fwnode);
-
#endif
diff --git a/drivers/hwtracing/coresight/coresight.c
b/drivers/hwtracing/coresight/coresight.c
index 55db77f6410b..6453c67a4d01 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -1046,9 +1046,7 @@ static void coresight_fixup_device_conns(struct
coresight_device *csdev)
struct coresight_connection *conn = &csdev->pdata->conns[i];
struct device
Re: 5.1.18 oops: echo source > /sys/class/typec/port0/preferred_role
Hi Doug, On Tue, Jul 23, 2019 at 07:26:34PM -0400, Douglas Gilbert wrote: > Hi, > Apologies if this is not code you maintain or the wrong medium. > No worries. You should copy the respective mailing lists, but I'll do that for you. > I'm experimenting with a NXP OM 13588 board (USB Type C Arduino shield) > on a Atmel SAMA5D2_XPLAINED board running lk 5.1.18 and Debian 10 . > When I did the "echo" command in the subject line to sysfs I saw the > following: > > [28988.75] Unable to handle kernel NULL pointer dereference at virtual > address 0028 > [28988.75] pgd = f69149ad > [28988.76] [0028] *pgd= > [28988.76] Internal error: Oops: 5 [#1] THUMB2 > [28988.76] Modules linked in: tcpci tcpm > [28988.76] CPU: 0 PID: 1882 Comm: bash Not tainted 5.1.18-sama5-armv7-r2 > #4 > [28988.76] Hardware name: Atmel SAMA5 > [28988.76] PC is at tcpm_try_role+0x3a/0x4c [tcpm] > [28988.76] LR is at tcpm_try_role+0x15/0x4c [tcpm] > [28988.76] pc : []lr : []psr: 60030033 > [28988.76] sp : dc1a1e88 ip : c03fb47d fp : > [28988.76] r10: dc216190 r9 : dc1a1f78 r8 : 0001 > [28988.76] r7 : df4ae044 r6 : dd032e90 r5 : dd1ce340 r4 : df4ae054 > [28988.76] r3 : r2 : r1 : r0 : df4ae044 > [28988.76] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment > none > [28988.76] Control: 50c53c7d Table: 3efec059 DAC: 0051 > [28988.76] Process bash (pid: 1882, stack limit = 0x6a6d4aa5) > [28988.76] Stack: (0xdc1a1e88 to 0xdc1a2000) > [28988.76] 1e80: dd05d808 dd1ce340 0001 0007 > dd1ce340 c03fb4a7 > [28988.76] 1ea0: 0007 0007 dc216180 c01e1e03 > > [28988.76] 1ec0: c0907008 dee98b40 c01e1d5d c06106c4 > 0007 c0194e8b > [28988.76] 1ee0: 000a 0400 c01a97db dc22bf00 e000 > df4b6a00 df745900 > [28988.76] 1f00: 0001 0001 00dd c01a9c2f 7aeab3be c0907008 > dc22bf00 > [28988.76] 1f20: c0907008 7aeab3be > 0007 dee98b40 > [28988.76] 1f40: 005dc318 dc1a1f78 0007 c01969f7 > 000a c01a20cb > [28988.76] 1f60: dee98b40 c0907008 dee98b40 005dc318 c0196b9b > > [28988.76] 1f80: dee98b40 7aeab3be 0074 005dc318 b6f3bdb0 0004 > c0101224 dc1a > [28988.76] 1fa0: 0004 c0101001 0074 005dc318 0001 005dc318 > 0007 > [28988.76] 1fc0: 0074 005dc318 b6f3bdb0 0004 0007 0007 > > [28988.76] 1fe0: 0004 be800880 b6ed35b3 b6e5c746 60030030 0001 > > [28988.76] [] (tcpm_try_role [tcpm]) from [] > (preferred_role_store+0x2b/0x5c) > [28988.76] [] (preferred_role_store) from [] > (kernfs_fop_write+0xa7/0x150) > [28988.76] [] (kernfs_fop_write) from [] > (__vfs_write+0x1f/0x104) > [28988.76] [] (__vfs_write) from [] > (vfs_write+0x6b/0x104) > [28988.76] [] (vfs_write) from [] > (ksys_write+0x43/0x94) > [28988.76] [] (ksys_write) from [] > (ret_fast_syscall+0x1/0x62) > [28988.76] Exception stack(0xdc1a1fa8 to 0xdc1a1ff0) > [28988.76] 1fa0: 0074 005dc318 0001 005dc318 > 0007 > [28988.76] 1fc0: 0074 005dc318 b6f3bdb0 0004 0007 0007 > > [28988.76] 1fe0: 0004 be800880 b6ed35b3 b6e5c746 > [28988.76] Code: 4628 e8bd 81f0 6833 (f893) 5028 > [28989.02] ---[ end trace d842183af2e975d9 ]--- > > The dts file is attached. It is not quite right since OF complains it > can't find that port (but there really isn't a "port" from the > "xplained" board's Point of view with my set up). The full oops is > also attached. > > Doug Gilbert Can you try the following ? Thanks, Guenter --- diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index fba32d84e578..6edacf60a226 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -4114,7 +4114,7 @@ static int tcpm_try_role(const struct typec_capability *cap, int role) mutex_lock(&port->lock); if (tcpc->try_role) ret = tcpc->try_role(tcpc, role); - if (!ret && !tcpc->config->try_role_hw) + if (!ret && (!tcpc->config || !tcpc->config->try_role_hw)) port->try_role = role; port->try_src_count = 0; port->try_snk_count = 0;
Re: [PATCH v2 2/2] usbip: Implement SG support to vhci
Hi Suwan,
On 7/5/19 10:43 AM, Suwan Kim wrote:
There are bugs on vhci with usb 3.0 storage device. Originally, vhci
doesn't supported SG, so USB storage driver on vhci breaks SG list
into multiple URBs and it causes error that a transfer got terminated
too early because the transfer length for one of the URBs was not
divisible by the maxpacket size.
In this patch, vhci basically support SG and it sends each SG list
entry to the stub driver. Then, the stub driver sees the total length
of the buffer and allocates SG table and pages according to the total
buffer length calling sgl_alloc(). After the stub driver receives
completed URB, it again sends each SG list entry to vhci.
If HCD of the server doesn't support SG, the stub driver breaks a
single SG reqeust into several URBs and submit them to the server's
HCD. When all the split URBs are completed, the stub driver
reassembles the URBs into a single return command and sends it to
vhci.
Signed-off-by: Suwan Kim
---
drivers/usb/usbip/stub.h | 7 +-
drivers/usb/usbip/stub_main.c| 52 +---
drivers/usb/usbip/stub_rx.c | 207 ++-
drivers/usb/usbip/stub_tx.c | 108 +++-
drivers/usb/usbip/usbip_common.c | 60 +++-- >
drivers/usb/usbip/vhci_hcd.c | 10 +-
drivers/usb/usbip/vhci_tx.c | 49 ++--
7 files changed, 372 insertions(+), 121 deletions(-)
While you are working on v3 to fix chekpatch and other issues
I pointed out, I have more for you.
What happens when you have mismatched server and client side?
i.e stub does and vhci doesn't and vice versa.
Make sure to run checkpatch. Also check spelling errors in
comments and your commit log.
I am not sure if your eeror paths are correct. Run usbip_test.sh
tools/testing/selftests/drivers/usb/usbip
diff --git a/drivers/usb/usbip/stub.h b/drivers/usb/usbip/stub.h
index 35618ceb2791..d11270560c24 100644
--- a/drivers/usb/usbip/stub.h
+++ b/drivers/usb/usbip/stub.h
@@ -52,7 +52,11 @@ struct stub_priv {
unsigned long seqnum;
struct list_head list;
struct stub_device *sdev;
- struct urb *urb;
+ struct urb **urbs;
+ struct scatterlist *sgl;
+ int num_urbs;
+ int completed_urbs;
+ int urb_status;
int unlinking;
};
@@ -86,6 +90,7 @@ extern struct usb_device_driver stub_driver;
struct bus_id_priv *get_busid_priv(const char *busid);
void put_busid_priv(struct bus_id_priv *bid);
int del_match_busid(char *busid);
+void stub_free_priv_and_urb(struct stub_priv *priv);
void stub_device_cleanup_urbs(struct stub_device *sdev);
/* stub_rx.c */
diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c
index 2e4bfccd4bfc..dec5af9f7179 100644
--- a/drivers/usb/usbip/stub_main.c
+++ b/drivers/usb/usbip/stub_main.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include "usbip_common.h"
#include "stub.h"
@@ -288,6 +289,39 @@ static struct stub_priv
*stub_priv_pop_from_listhead(struct list_head *listhead)
return NULL;
}
+void stub_free_priv_and_urb(struct stub_priv *priv)
+{
+ struct urb *urb;
+ int i;
+
+ for (i = 0; i < priv->num_urbs; i++) {
+ urb = priv->urbs[i];
+ if (urb->setup_packet) {
+ kfree(urb->setup_packet);
+ urb->setup_packet = NULL;
+ }
+
+ if (urb->transfer_buffer && !priv->sgl) {
+ kfree(urb->transfer_buffer);
+ urb->transfer_buffer = NULL;
+ }
+
+ if (urb->num_sgs) {
+ sgl_free(urb->sg);
+ urb->sg = NULL;
+ urb->num_sgs = 0;
+ }
+
+ usb_free_urb(urb);
+ }
+
+ list_del(&priv->list);
+ if (priv->sgl)
+ sgl_free(priv->sgl);
+ kfree(priv->urbs);
+ kmem_cache_free(stub_priv_cache, priv);
+}
+
static struct stub_priv *stub_priv_pop(struct stub_device *sdev)
{
unsigned long flags;
@@ -314,25 +348,15 @@ static struct stub_priv *stub_priv_pop(struct stub_device
*sdev)
void stub_device_cleanup_urbs(struct stub_device *sdev)
{
struct stub_priv *priv;
- struct urb *urb;
+ int i;
dev_dbg(&sdev->udev->dev, "Stub device cleaning up urbs\n");
while ((priv = stub_priv_pop(sdev))) {
- urb = priv->urb;
- dev_dbg(&sdev->udev->dev, "free urb seqnum %lu\n",
- priv->seqnum);
- usb_kill_urb(urb);
-
- kmem_cache_free(stub_priv_cache, priv);
-
- kfree(urb->transfer_buffer);
- urb->transfer_buffer = NULL;
+ for (i = 0; i < priv->num_urbs; i++)
+ usb_kill_urb(priv->urbs[i]);
- kfree(urb->setup_packet);
- urb->setup_packet = NULL;
-
- usb_free_urb(urb);
+
Reminder: 67 open syzbot bugs in usb subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 67 of them as possibly being bugs in the usb subsystem. This category mostly includes USB driver bugs, but it might include some core USB bugs too. I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 67 bugs, 47 were seen in mainline in the last week. If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the usb subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: possible deadlock in mon_bin_vma_fault Last occurred: 0 days ago Reported: 323 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=2b061d1fabd9760e98f92163543189b637c4af36 Original thread: https://lkml.kernel.org/lkml/6ad6030574fea...@google.com/T/#u This bug has a C reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+56f9673bb4cdcbeb0...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/6ad6030574fea...@google.com Title: WARNING in rollback_registered_many (2) Last occurred: 0 days ago Reported: 258 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=d39aca7a05a76d146ba96cddbb3242075d9171a7 Original thread: https://lkml.kernel.org/lkml/d9f094057a17b...@google.com/T/#u This bug has a C reproducer. The original thread for this bug received 1 reply, 102 days ago. This looks like a bug in a net USB driver. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+40918e4d826fb2ff9...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/d9f094057a17b...@google.com Title: general protection fault in ath6kl_usb_alloc_urb_from_pipe Last occurred: 0 days ago Reported: 102 days ago Branches: Mainline (with usb-fuzzer patches) Dashboard link: https://syzkaller.appspot.com/bug?id=cd8b9cfe50a0bf36ee19eda2d7e2e06843dfbeaf Original thread: https://lkml.kernel.org/lkml/8e82510586561...@google.com/T/#u This bug has a C reproducer. No one replied to the original thread for this bug. This looks like a bug in a net/wireless USB driver. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+ead4037ec793e025e...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/8e82510586561...@google.com Title: general protection fault in flexcop_usb_probe Last occurred: 0 days ago Reported: 102 days ago Branches: Mainline (with usb-fuzzer patches) Dashboard link: https://syzkaller.appspot.com/bug?id=c0203bd72037d07493f4b7562411e4f5f4553a8f Original thread: https://lkml.kernel.org/lkml/10fe260586536...@google.com/T/#u This bug has a C reproducer. No one replied to the original thread for this bug. This looks like a bug in a media USB driver. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+d93dff37e6a89431c...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/10fe260
[PATCH] usb: wusbcore: fix unbalanced get/put cluster_id
syzboot reported that https://syzkaller.appspot.com/bug?extid=fd2bd7df88c606eea4ef There is not consitency parameter in cluste_id_get/put calling. In case of getting the id with result is failure, the wusbhc->cluster_id will not be updated and this can not be used for wusb_cluster_id_put(). Tested report https://groups.google.com/d/msg/syzkaller-bugs/0znZopp3-9k/oxOrhLkLEgAJ Reported-by: syzbot+fd2bd7df88c606eea...@syzkaller.appspotmail.com Reproduce and gdb got the details: 139 addr = wusb_cluster_id_get(); (gdb) n 140 if (addr == 0) (gdb) print addr $1 = 254 '\376' (gdb) n 142 result = __hwahc_set_cluster_id(hwahc, addr); (gdb) print result $2 = -71 (gdb) break wusb_cluster_id_put Breakpoint 3 at 0x836e3f20: file drivers/usb/wusbcore/wusbhc.c, line 384. (gdb) s Thread 2 hit Breakpoint 3, wusb_cluster_id_put (id=0 '\000') at drivers/usb/wusbcore/wusbhc.c:384 384 id = 0xff - id; (gdb) n 385 BUG_ON(id >= CLUSTER_IDS); (gdb) print id $3 = 255 '\377' Signed-off-by: Phong Tran --- drivers/usb/host/hwa-hc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/hwa-hc.c b/drivers/usb/host/hwa-hc.c index 09a8ebd95588..6968b9f2b76b 100644 --- a/drivers/usb/host/hwa-hc.c +++ b/drivers/usb/host/hwa-hc.c @@ -159,7 +159,7 @@ static int hwahc_op_start(struct usb_hcd *usb_hcd) return result; error_set_cluster_id: - wusb_cluster_id_put(wusbhc->cluster_id); + wusb_cluster_id_put(addr); error_cluster_id_get: goto out; -- 2.20.1
Re: [PATCH] USB: serial: option: Add Motorola modem UARTs
On 7/23/2019 21:49, Tony Lindgren wrote: +#define MOTOROLA_VENDOR_ID 0x22b8 +#define MOTOROLA_PRODUCT_MDM6600 0x2a70 +#define MOTOROLA_PRODUCT_MDM9600 0x2e0a +#define MOTOROLA_PRODUCT_MDM_RAM_DL0x4281 +#define MOTOROLA_PRODUCT_MDM_QC_DL 0x900e + Johan, when he is back from vacation, will tell you to drop those defines and instead use the values directly in the list with a comment behind reflecting the device model. Just telling you so you can save time by sending out your v2 early.. best rgds /Lars
Re: 5.1.18 oops: echo source > /sys/class/typec/port0/preferred_role
On 2019-07-23 7:55 p.m., Guenter Roeck wrote: Hi Doug, On Tue, Jul 23, 2019 at 07:26:34PM -0400, Douglas Gilbert wrote: Hi, Apologies if this is not code you maintain or the wrong medium. No worries. You should copy the respective mailing lists, but I'll do that for you. I'm experimenting with a NXP OM 13588 board (USB Type C Arduino shield) on a Atmel SAMA5D2_XPLAINED board running lk 5.1.18 and Debian 10 . When I did the "echo" command in the subject line to sysfs I saw the following: [28988.75] Unable to handle kernel NULL pointer dereference at virtual address 0028 [28988.75] pgd = f69149ad [28988.76] [0028] *pgd= [28988.76] Internal error: Oops: 5 [#1] THUMB2 [28988.76] Modules linked in: tcpci tcpm [28988.76] CPU: 0 PID: 1882 Comm: bash Not tainted 5.1.18-sama5-armv7-r2 #4 [28988.76] Hardware name: Atmel SAMA5 [28988.76] PC is at tcpm_try_role+0x3a/0x4c [tcpm] [28988.76] LR is at tcpm_try_role+0x15/0x4c [tcpm] [28988.76] pc : []lr : []psr: 60030033 [28988.76] sp : dc1a1e88 ip : c03fb47d fp : [28988.76] r10: dc216190 r9 : dc1a1f78 r8 : 0001 [28988.76] r7 : df4ae044 r6 : dd032e90 r5 : dd1ce340 r4 : df4ae054 [28988.76] r3 : r2 : r1 : r0 : df4ae044 [28988.76] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment none [28988.76] Control: 50c53c7d Table: 3efec059 DAC: 0051 [28988.76] Process bash (pid: 1882, stack limit = 0x6a6d4aa5) [28988.76] Stack: (0xdc1a1e88 to 0xdc1a2000) [28988.76] 1e80: dd05d808 dd1ce340 0001 0007 dd1ce340 c03fb4a7 [28988.76] 1ea0: 0007 0007 dc216180 c01e1e03 [28988.76] 1ec0: c0907008 dee98b40 c01e1d5d c06106c4 0007 c0194e8b [28988.76] 1ee0: 000a 0400 c01a97db dc22bf00 e000 df4b6a00 df745900 [28988.76] 1f00: 0001 0001 00dd c01a9c2f 7aeab3be c0907008 dc22bf00 [28988.76] 1f20: c0907008 7aeab3be 0007 dee98b40 [28988.76] 1f40: 005dc318 dc1a1f78 0007 c01969f7 000a c01a20cb [28988.76] 1f60: dee98b40 c0907008 dee98b40 005dc318 c0196b9b [28988.76] 1f80: dee98b40 7aeab3be 0074 005dc318 b6f3bdb0 0004 c0101224 dc1a [28988.76] 1fa0: 0004 c0101001 0074 005dc318 0001 005dc318 0007 [28988.76] 1fc0: 0074 005dc318 b6f3bdb0 0004 0007 0007 [28988.76] 1fe0: 0004 be800880 b6ed35b3 b6e5c746 60030030 0001 [28988.76] [] (tcpm_try_role [tcpm]) from [] (preferred_role_store+0x2b/0x5c) [28988.76] [] (preferred_role_store) from [] (kernfs_fop_write+0xa7/0x150) [28988.76] [] (kernfs_fop_write) from [] (__vfs_write+0x1f/0x104) [28988.76] [] (__vfs_write) from [] (vfs_write+0x6b/0x104) [28988.76] [] (vfs_write) from [] (ksys_write+0x43/0x94) [28988.76] [] (ksys_write) from [] (ret_fast_syscall+0x1/0x62) [28988.76] Exception stack(0xdc1a1fa8 to 0xdc1a1ff0) [28988.76] 1fa0: 0074 005dc318 0001 005dc318 0007 [28988.76] 1fc0: 0074 005dc318 b6f3bdb0 0004 0007 0007 [28988.76] 1fe0: 0004 be800880 b6ed35b3 b6e5c746 [28988.76] Code: 4628 e8bd 81f0 6833 (f893) 5028 [28989.02] ---[ end trace d842183af2e975d9 ]--- The dts file is attached. It is not quite right since OF complains it can't find that port (but there really isn't a "port" from the "xplained" board's Point of view with my set up). The full oops is also attached. Doug Gilbert Can you try the following ? Thanks, Guenter --- diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index fba32d84e578..6edacf60a226 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -4114,7 +4114,7 @@ static int tcpm_try_role(const struct typec_capability *cap, int role) mutex_lock(&port->lock); if (tcpc->try_role) ret = tcpc->try_role(tcpc, role); - if (!ret && !tcpc->config->try_role_hw) + if (!ret && (!tcpc->config || !tcpc->config->try_role_hw)) port->try_role = role; port->try_src_count = 0; port->try_snk_count = 0; Tested by: Douglas Gilbert That fixed the oops.
Re: High-Impact: xhci_hid - "Not enough bandwidth for new device state"
On Tue, Jul 23, 2019 at 04:27:51PM +0200, Frank Bergmann wrote: > > configuration of your devices and root hubs > > > I've got a brand new Dell XPX 15 9370 Laptop. No other USB hubs, devices, no > change to any configuration. I chose the model because it is supposed to be > the same that Linus Torvalds uses (well, XPS 13...) I too have the XPS 13, and it is very different from the XPX 15 last I looked, so I do not think you can compare the two, sorry. The debugging information that Alan asked for should help here. thanks, greg k-h
