Re: INFO: task hung in usb_bulk_msg

Re: INFO: task hung in usb_bulk_msg

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:    15bc20c6 Merge tag 'tty-5.9-rc3' of git://git.kernel.org/p..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1052a669900000
kernel config:  https://syzkaller.appspot.com/x/.config?x=978db74cb30aa994
dashboard link: https://syzkaller.appspot.com/bug?extid=7a7613e5ba9ae7bd15f9
compiler:       gcc (GCC) 10.1.0-syz 20200507
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=101c328e900000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=155eff41900000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+7a7613e5ba9ae7bd15f9@syzkaller.appspotmail.com

INFO: task syz-executor790:9958 blocked for more than 143 seconds.
      Not tainted 5.9.0-rc2-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor790 state:D stack:28240 pid: 9958 ppid:  6854 flags:0x00004004
Call Trace:
 context_switch kernel/sched/core.c:3778 [inline]
 __schedule+0x8e5/0x21e0 kernel/sched/core.c:4527
 schedule+0xd0/0x2a0 kernel/sched/core.c:4602
 schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1855
 do_wait_for_common kernel/sched/completion.c:85 [inline]
 __wait_for_common kernel/sched/completion.c:106 [inline]
 wait_for_common kernel/sched/completion.c:117 [inline]
 wait_for_completion_timeout+0x15e/0x270 kernel/sched/completion.c:157
 usb_start_wait_urb+0x144/0x2b0 drivers/usb/core/message.c:63
 usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:254
 do_proc_bulk+0x39b/0x710 drivers/usb/core/devio.c:1231
 proc_bulk drivers/usb/core/devio.c:1268 [inline]
 usbdev_do_ioctl drivers/usb/core/devio.c:2542 [inline]
 usbdev_ioctl+0x586/0x3360 drivers/usb/core/devio.c:2708
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl fs/ioctl.c:739 [inline]
 __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x44d089
Code: Bad RIP value.
RSP: 002b:00007f70887dadb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000006dec48 RCX: 000000000044d089
RDX: 0000000020000000 RSI: 00000000c0185502 RDI: 0000000000000003
RBP: 00000000006dec40 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dec4c
R13: 00007ffebdfc131f R14: 00007f70887db9c0 R15: 0000000000000064

Showing all locks held in the system:
1 lock held by ksoftirqd/1/16:
 #0: ffff8880ae735e18 (&rq->lock){-.-.}-{2:2}, at: rq_lock kernel/sched/sched.h:1292 [inline]
 #0: ffff8880ae735e18 (&rq->lock){-.-.}-{2:2}, at: __schedule+0x232/0x21e0 kernel/sched/core.c:4445
1 lock held by khungtaskd/1169:
 #0: ffffffff89bd6900 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:5825
1 lock held by in:imklog/6531:
 #0: ffff8880a83bab70 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:930
3 locks held by kworker/u4:0/6882:
1 lock held by syz-executor790/24330:
 #0: ffff8880ae635e18 (&rq->lock){-.-.}-{2:2}, at: rq_lock kernel/sched/sched.h:1292 [inline]
 #0: ffff8880ae635e18 (&rq->lock){-.-.}-{2:2}, at: __schedule+0x232/0x21e0 kernel/sched/core.c:4445

=============================================

NMI backtrace for cpu 0
CPU: 0 PID: 1169 Comm: khungtaskd Not tainted 5.9.0-rc2-syzkaller #0
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+0x18f/0x20d lib/dump_stack.c:118
 nmi_cpu_backtrace.cold+0x70/0xb1 lib/nmi_backtrace.c:101
 nmi_trigger_cpumask_backtrace+0x1b3/0x223 lib/nmi_backtrace.c:62
 trigger_all_cpu_backtrace include/linux/nmi.h:146 [inline]
 check_hung_uninterruptible_tasks kernel/hung_task.c:209 [inline]
 watchdog+0xd7d/0x1000 kernel/hung_task.c:295
 kthread+0x3b5/0x4a0 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 6851 Comm: syz-executor790 Not tainted 5.9.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:get_timespec64+0x1b3/0x220 kernel/time/time.c:801
Code: 89 73 08 e8 8f f6 10 00 48 b8 00 00 00 00 00 fc ff df 49 c7 04 04 00 00 00 00 48 8b 44 24 58 65 48 2b 04 25 28 00 00 00 75 45 <48> 83 c4 60 44 89 e8 5b 5d 41 5c 41 5d 41 5e c3 e8 58 f6 10 00 45
RSP: 0018:ffffc90001667e20 EFLAGS: 00000246
RAX: 0000000000000000 RBX: ffffc90001667ed0 RCX: ffffffff81634853
RDX: ffff8880a77381c0 RSI: ffffffff81634881 RDI: ffffc90001667ed8
RBP: 0000000000000000 R08: 00000000000f4240 R09: ffffc90001667e4f
R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff920002ccfc4
R13: 0000000000000000 R14: 00000000000f4240 R15: 0000000000000000
FS:  000000000153e880(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004c6238 CR3: 00000000a93cd000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 __do_sys_nanosleep kernel/time/hrtimer.c:1962 [inline]
 __se_sys_nanosleep kernel/time/hrtimer.c:1957 [inline]
 __x64_sys_nanosleep+0xaa/0x260 kernel/time/hrtimer.c:1957
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x44b800
Code: c0 5b 5d c3 66 0f 1f 44 00 00 8b 04 24 48 83 c4 18 5b 5d c3 66 0f 1f 44 00 00 83 3d b1 a0 29 00 00 75 14 b8 23 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 24 e4 fb ff c3 48 83 ec 08 e8 7a 43 00 00
RSP: 002b:00007ffebdfc1378 EFLAGS: 00000246 ORIG_RAX: 0000000000000023
RAX: ffffffffffffffda RBX: 00000000000025c4 RCX: 000000000044b800
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007ffebdfc1380
RBP: 000000000009bbed R08: 0000000000000001 R09: 000000000153e880
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffebdfc13e0
R13: 000000000040a140 R14: 0000000000000000 R15: 0000000000000000

Re: INFO: task hung in usb_bulk_msg

[Andy Shevchenko]

On Fri, Aug 28, 2020 at 05:52:16AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
> 
> HEAD commit:    15bc20c6 Merge tag 'tty-5.9-rc3' of git://git.kernel.org/p..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1052a669900000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=978db74cb30aa994
> dashboard link: https://syzkaller.appspot.com/bug?extid=7a7613e5ba9ae7bd15f9
> compiler:       gcc (GCC) 10.1.0-syz 20200507
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=101c328e900000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=155eff41900000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+7a7613e5ba9ae7bd15f9@syzkaller.appspotmail.com

I have had hard times to understand the link between tty subsystem and this
report. Also I'm wondering how 'Maintainers' column is formed in the dashboard
view. And how the Cc list of this message in particular.

-- 
With Best Regards,
Andy Shevchenko

Re: INFO: task hung in usb_bulk_msg

[Alan Stern]

On Fri, Aug 28, 2020 at 05:52:16AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
> 
> HEAD commit:    15bc20c6 Merge tag 'tty-5.9-rc3' of git://git.kernel.org/p..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1052a669900000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=978db74cb30aa994
> dashboard link: https://syzkaller.appspot.com/bug?extid=7a7613e5ba9ae7bd15f9
> compiler:       gcc (GCC) 10.1.0-syz 20200507
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=101c328e900000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=155eff41900000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+7a7613e5ba9ae7bd15f9@syzkaller.appspotmail.com
> 
> INFO: task syz-executor790:9958 blocked for more than 143 seconds.
>       Not tainted 5.9.0-rc2-syzkaller #0
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> task:syz-executor790 state:D stack:28240 pid: 9958 ppid:  6854 flags:0x00004004
> Call Trace:
>  context_switch kernel/sched/core.c:3778 [inline]
>  __schedule+0x8e5/0x21e0 kernel/sched/core.c:4527
>  schedule+0xd0/0x2a0 kernel/sched/core.c:4602
>  schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1855
>  do_wait_for_common kernel/sched/completion.c:85 [inline]
>  __wait_for_common kernel/sched/completion.c:106 [inline]
>  wait_for_common kernel/sched/completion.c:117 [inline]
>  wait_for_completion_timeout+0x15e/0x270 kernel/sched/completion.c:157
>  usb_start_wait_urb+0x144/0x2b0 drivers/usb/core/message.c:63
>  usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:254
>  do_proc_bulk+0x39b/0x710 drivers/usb/core/devio.c:1231
>  proc_bulk drivers/usb/core/devio.c:1268 [inline]
>  usbdev_do_ioctl drivers/usb/core/devio.c:2542 [inline]
>  usbdev_ioctl+0x586/0x3360 drivers/usb/core/devio.c:2708

I'm confused about this bug report.

Here's the syz reproducer from the link listed above:

# 
https://syzkaller.appspot.com/bug?id=bf172344c5f1d3487a4feff67c3dd30e08d5b635
# See https://goo.gl/kgGztJ for information about syzkaller reproducers.
#{"threaded":true,"repeat":true,"procs":6,"sandbox":"none","fault_call":-1,"netdev":true,"close_fds":true}
r0 = syz_open_dev$usbfs(&(0x7f0000000040)='/dev/bus/usb/00#/00#\x00', 
0x4000000000000071, 0x28081)
r1 = socket$inet6(0xa, 0x2, 0x0)
r2 = dup(r1)
ioctl$PERF_EVENT_IOC_ENABLE(r2, 0x8912, 0x400200)
socketpair$unix(0x1, 0x0, 0x0, &(0x7f0000000000))
ioctl$USBDEVFS_CONTROL(r0, 0x8108551b, &(0x7f0000001140)={0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0})
ioctl$USBDEVFS_CLEAR_HALT(r0, 0xc0185502, &(0x7f0000000000)={0x1, 0x1})

As far as I can see, the only USB ioctls used in this test are 
USBDEVFS_CONTROL and USBDEVFS_CLEAR_HALT.  Neither of those calls 
do_proc_bulk() or usb_bulk_msg(), so how did those routines end up in 
the stack trace?

In fact, do_proc_bulk() is called only for USBDEVFS_BULK.  But the test 
doesn't use that ioctl!

What's going on?  Am I missing part of the test?

Alan Stern

Re: INFO: task hung in usb_bulk_msg

[Andrey Konovalov]

On Sat, Aug 29, 2020 at 3:24 AM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Fri, Aug 28, 2020 at 05:52:16AM -0700, syzbot wrote:
> > syzbot has found a reproducer for the following issue on:
> >
> > HEAD commit:    15bc20c6 Merge tag 'tty-5.9-rc3' of git://git.kernel.org/p..
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1052a669900000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=978db74cb30aa994
> > dashboard link: https://syzkaller.appspot.com/bug?extid=7a7613e5ba9ae7bd15f9
> > compiler:       gcc (GCC) 10.1.0-syz 20200507
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=101c328e900000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=155eff41900000
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+7a7613e5ba9ae7bd15f9@syzkaller.appspotmail.com
> >
> > INFO: task syz-executor790:9958 blocked for more than 143 seconds.
> >       Not tainted 5.9.0-rc2-syzkaller #0
> > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > task:syz-executor790 state:D stack:28240 pid: 9958 ppid:  6854 flags:0x00004004
> > Call Trace:
> >  context_switch kernel/sched/core.c:3778 [inline]
> >  __schedule+0x8e5/0x21e0 kernel/sched/core.c:4527
> >  schedule+0xd0/0x2a0 kernel/sched/core.c:4602
> >  schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1855
> >  do_wait_for_common kernel/sched/completion.c:85 [inline]
> >  __wait_for_common kernel/sched/completion.c:106 [inline]
> >  wait_for_common kernel/sched/completion.c:117 [inline]
> >  wait_for_completion_timeout+0x15e/0x270 kernel/sched/completion.c:157
> >  usb_start_wait_urb+0x144/0x2b0 drivers/usb/core/message.c:63
> >  usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:254
> >  do_proc_bulk+0x39b/0x710 drivers/usb/core/devio.c:1231
> >  proc_bulk drivers/usb/core/devio.c:1268 [inline]
> >  usbdev_do_ioctl drivers/usb/core/devio.c:2542 [inline]
> >  usbdev_ioctl+0x586/0x3360 drivers/usb/core/devio.c:2708
>
> I'm confused about this bug report.
>
> Here's the syz reproducer from the link listed above:
>
> #
> https://syzkaller.appspot.com/bug?id=bf172344c5f1d3487a4feff67c3dd30e08d5b635
> # See https://goo.gl/kgGztJ for information about syzkaller reproducers.
> #{"threaded":true,"repeat":true,"procs":6,"sandbox":"none","fault_call":-1,"netdev":true,"close_fds":true}
> r0 = syz_open_dev$usbfs(&(0x7f0000000040)='/dev/bus/usb/00#/00#\x00',
> 0x4000000000000071, 0x28081)
> r1 = socket$inet6(0xa, 0x2, 0x0)
> r2 = dup(r1)
> ioctl$PERF_EVENT_IOC_ENABLE(r2, 0x8912, 0x400200)
> socketpair$unix(0x1, 0x0, 0x0, &(0x7f0000000000))
> ioctl$USBDEVFS_CONTROL(r0, 0x8108551b, &(0x7f0000001140)={0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0})
> ioctl$USBDEVFS_CLEAR_HALT(r0, 0xc0185502, &(0x7f0000000000)={0x1, 0x1})
>
> As far as I can see, the only USB ioctls used in this test are
> USBDEVFS_CONTROL and USBDEVFS_CLEAR_HALT.  Neither of those calls
> do_proc_bulk() or usb_bulk_msg(), so how did those routines end up in
> the stack trace?
>
> In fact, do_proc_bulk() is called only for USBDEVFS_BULK.  But the test
> doesn't use that ioctl!
>
> What's going on?  Am I missing part of the test?

Hi Alan,

Yeah, it's a bit confusing, sorry for that. Since syzkaller mutates
the values that are passed into syscalls, it might mutate the cmd
value of an ioctl. This results in a mismatch between the name of a
syscall in syzkaller's notation, and the actual cmd value. In this
case we have:

ioctl$USBDEVFS_CONTROL(r0, 0x8108551b, ...)

where 0x8108551b == 2164806939, which is the value for
USBDEVFS_DISCONNECT_CLAIM [1], and

ioctl$USBDEVFS_CLEAR_HALT(r0, 0xc0185502, ...)

where 0xc0185502 == 3222820098, which is the value for USBDEVFS_BULK [2].

I remember Dmitry did some changes to this part, but I think syzkaller
only avoids getting disabled ioctls during mutations. Dmitry, maybe it
would make sense to avoid getting other known ioctls during mutations?

Thanks!

[1] https://github.com/google/syzkaller/blob/master/sys/linux/dev_bus_usb.txt.const#L13
[2] https://github.com/google/syzkaller/blob/master/sys/linux/dev_bus_usb.txt.const#L4

Re: INFO: task hung in usb_bulk_msg

[Dmitry Vyukov]

On Mon, Aug 31, 2020 at 3:08 PM 'Andrey Konovalov' via syzkaller-bugs
<syzkaller-bugs@googlegroups.com> wrote:
>
> On Sat, Aug 29, 2020 at 3:24 AM Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > On Fri, Aug 28, 2020 at 05:52:16AM -0700, syzbot wrote:
> > > syzbot has found a reproducer for the following issue on:
> > >
> > > HEAD commit:    15bc20c6 Merge tag 'tty-5.9-rc3' of git://git.kernel.org/p..
> > > git tree:       upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=1052a669900000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=978db74cb30aa994
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=7a7613e5ba9ae7bd15f9
> > > compiler:       gcc (GCC) 10.1.0-syz 20200507
> > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=101c328e900000
> > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=155eff41900000
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+7a7613e5ba9ae7bd15f9@syzkaller.appspotmail.com
> > >
> > > INFO: task syz-executor790:9958 blocked for more than 143 seconds.
> > >       Not tainted 5.9.0-rc2-syzkaller #0
> > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > > task:syz-executor790 state:D stack:28240 pid: 9958 ppid:  6854 flags:0x00004004
> > > Call Trace:
> > >  context_switch kernel/sched/core.c:3778 [inline]
> > >  __schedule+0x8e5/0x21e0 kernel/sched/core.c:4527
> > >  schedule+0xd0/0x2a0 kernel/sched/core.c:4602
> > >  schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1855
> > >  do_wait_for_common kernel/sched/completion.c:85 [inline]
> > >  __wait_for_common kernel/sched/completion.c:106 [inline]
> > >  wait_for_common kernel/sched/completion.c:117 [inline]
> > >  wait_for_completion_timeout+0x15e/0x270 kernel/sched/completion.c:157
> > >  usb_start_wait_urb+0x144/0x2b0 drivers/usb/core/message.c:63
> > >  usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:254
> > >  do_proc_bulk+0x39b/0x710 drivers/usb/core/devio.c:1231
> > >  proc_bulk drivers/usb/core/devio.c:1268 [inline]
> > >  usbdev_do_ioctl drivers/usb/core/devio.c:2542 [inline]
> > >  usbdev_ioctl+0x586/0x3360 drivers/usb/core/devio.c:2708
> >
> > I'm confused about this bug report.
> >
> > Here's the syz reproducer from the link listed above:
> >
> > #
> > https://syzkaller.appspot.com/bug?id=bf172344c5f1d3487a4feff67c3dd30e08d5b635
> > # See https://goo.gl/kgGztJ for information about syzkaller reproducers.
> > #{"threaded":true,"repeat":true,"procs":6,"sandbox":"none","fault_call":-1,"netdev":true,"close_fds":true}
> > r0 = syz_open_dev$usbfs(&(0x7f0000000040)='/dev/bus/usb/00#/00#\x00',
> > 0x4000000000000071, 0x28081)
> > r1 = socket$inet6(0xa, 0x2, 0x0)
> > r2 = dup(r1)
> > ioctl$PERF_EVENT_IOC_ENABLE(r2, 0x8912, 0x400200)
> > socketpair$unix(0x1, 0x0, 0x0, &(0x7f0000000000))
> > ioctl$USBDEVFS_CONTROL(r0, 0x8108551b, &(0x7f0000001140)={0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0})
> > ioctl$USBDEVFS_CLEAR_HALT(r0, 0xc0185502, &(0x7f0000000000)={0x1, 0x1})
> >
> > As far as I can see, the only USB ioctls used in this test are
> > USBDEVFS_CONTROL and USBDEVFS_CLEAR_HALT.  Neither of those calls
> > do_proc_bulk() or usb_bulk_msg(), so how did those routines end up in
> > the stack trace?
> >
> > In fact, do_proc_bulk() is called only for USBDEVFS_BULK.  But the test
> > doesn't use that ioctl!
> >
> > What's going on?  Am I missing part of the test?
>
> Hi Alan,
>
> Yeah, it's a bit confusing, sorry for that. Since syzkaller mutates
> the values that are passed into syscalls, it might mutate the cmd
> value of an ioctl. This results in a mismatch between the name of a
> syscall in syzkaller's notation, and the actual cmd value. In this
> case we have:
>
> ioctl$USBDEVFS_CONTROL(r0, 0x8108551b, ...)
>
> where 0x8108551b == 2164806939, which is the value for
> USBDEVFS_DISCONNECT_CLAIM [1], and
>
> ioctl$USBDEVFS_CLEAR_HALT(r0, 0xc0185502, ...)
>
> where 0xc0185502 == 3222820098, which is the value for USBDEVFS_BULK [2].
>
> I remember Dmitry did some changes to this part, but I think syzkaller
> only avoids getting disabled ioctls during mutations. Dmitry, maybe it
> would make sense to avoid getting other known ioctls during mutations?

Agree, it would make sense. I've started working on it but wasn't able
to finish. It also affects get/setsockopt, fcntl, prctl, bpf and
others. In this more general context it turns out to be an interesting
problem figuring out what is that exactly we don't want to mutate and
to what values.