WARNING in cm109_urb_irq_callback/usb_submit_urb

WARNING in cm109_urb_irq_callback/usb_submit_urb

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    5814bc2d Merge tag 'perf-tools-2020-12-24' of git://git.ke..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12f074db500000
kernel config:  https://syzkaller.appspot.com/x/.config?x=bf519e1e96191576
dashboard link: https://syzkaller.appspot.com/bug?extid=2d6d691af5ab4b7e66df
compiler:       gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

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

cm109 2-1:0.0: cm109_urb_irq_callback: urb status -71
------------[ cut here ]------------
URB 0000000096f203b6 submitted while active
WARNING: CPU: 0 PID: 18262 at drivers/usb/core/urb.c:378 usb_submit_urb+0x128e/0x1560 drivers/usb/core/urb.c:378
Modules linked in:
CPU: 0 PID: 18262 Comm: syz-executor.5 Not tainted 5.10.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:usb_submit_urb+0x128e/0x1560 drivers/usb/core/urb.c:378
Code: 89 de e8 55 99 31 fc 84 db 0f 85 74 f4 ff ff e8 68 91 31 fc 4c 89 fe 48 c7 c7 a0 c6 02 8a c6 05 4b 89 28 08 01 e8 f6 1c 89 03 <0f> 0b e9 52 f4 ff ff c7 44 24 14 01 00 00 00 e9 09 f5 ff ff 41 be
RSP: 0018:ffffc900000079e8 EFLAGS: 00010082
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000040000 RSI: ffffffff815b94d5 RDI: fffff52000000f2f
RBP: ffff88802517c4c0 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815b792b R11: 0000000000000000 R12: 0000000000000012
R13: ffff88801e060058 R14: 00000000fffffff0 R15: ffff88801f2b6500
FS:  0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2f62d000 CR3: 000000002aba6000 CR4: 00000000001526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <IRQ>
 cm109_urb_irq_callback+0x44f/0xaa0 drivers/input/misc/cm109.c:422
 __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1657
 usb_hcd_giveback_urb+0x38c/0x430 drivers/usb/core/hcd.c:1728
 dummy_timer+0x11f4/0x32a0 drivers/usb/gadget/udc/dummy_hcd.c:1971
 call_timer_fn+0x1a5/0x710 kernel/time/timer.c:1417
 expire_timers kernel/time/timer.c:1462 [inline]
 __run_timers.part.0+0x692/0xa80 kernel/time/timer.c:1731
 __run_timers kernel/time/timer.c:1712 [inline]
 run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1744
 __do_softirq+0x2bc/0xa77 kernel/softirq.c:343
 asm_call_irq_on_stack+0xf/0x20
 </IRQ>
 __run_on_irqstack arch/x86/include/asm/irq_stack.h:26 [inline]
 run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:77 [inline]
 do_softirq_own_stack+0xaa/0xd0 arch/x86/kernel/irq_64.c:77
 invoke_softirq kernel/softirq.c:226 [inline]
 __irq_exit_rcu+0x17f/0x200 kernel/softirq.c:420
 irq_exit_rcu+0x5/0x20 kernel/softirq.c:432
 sysvec_apic_timer_interrupt+0x4d/0x100 arch/x86/kernel/apic/apic.c:1096
 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:628
RIP: 0010:check_kcov_mode+0x2c/0x40 kernel/kcov.c:174
Code: 05 09 a8 8e 7e 89 c2 81 e2 00 01 00 00 a9 00 01 ff 00 74 10 31 c0 85 d2 74 15 8b 96 cc 14 00 00 85 d2 74 0b 8b 86 a8 14 00 00 <39> f8 0f 94 c0 c3 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 31 c0
RSP: 0018:ffffc90014ebf628 EFLAGS: 00000246
RAX: 0000000000000000 RBX: 00000000000001fe RCX: 00000000000000aa
RDX: 0000000000000000 RSI: ffff888066450280 RDI: 0000000000000003
RBP: ffffea00004ca500 R08: 00000000000001fe R09: 00000000004ca500
R10: ffffffff819a63e0 R11: 0000000000000000 R12: 0000000000000000
R13: ffff88802d906560 R14: 00000000000000aa R15: dffffc0000000000
 write_comp_data kernel/kcov.c:218 [inline]
 __sanitizer_cov_trace_cmp4+0x1c/0x70 kernel/kcov.c:258
 release_pages+0x6f0/0x1d60 mm/swap.c:864
 tlb_batch_pages_flush mm/mmu_gather.c:49 [inline]
 tlb_flush_mmu_free mm/mmu_gather.c:242 [inline]
 tlb_flush_mmu+0xe9/0x6b0 mm/mmu_gather.c:249
 zap_pte_range mm/memory.c:1330 [inline]
 zap_pmd_range mm/memory.c:1368 [inline]
 zap_pud_range mm/memory.c:1397 [inline]
 zap_p4d_range mm/memory.c:1418 [inline]
 unmap_page_range+0x1a75/0x2640 mm/memory.c:1439
 unmap_single_vma+0x198/0x300 mm/memory.c:1484
 unmap_vmas+0x168/0x2e0 mm/memory.c:1516
 exit_mmap+0x2b1/0x5a0 mm/mmap.c:3220
 __mmput+0x122/0x470 kernel/fork.c:1083
 mmput+0x53/0x60 kernel/fork.c:1104
 exit_mm kernel/exit.c:500 [inline]
 do_exit+0xa97/0x2a00 kernel/exit.c:810
 do_group_exit+0x125/0x310 kernel/exit.c:920
 get_signal+0x3e9/0x2160 kernel/signal.c:2770
 arch_do_signal_or_restart+0x2a8/0x1eb0 arch/x86/kernel/signal.c:811
 handle_signal_work kernel/entry/common.c:147 [inline]
 exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
 exit_to_user_mode_prepare+0x124/0x200 kernel/entry/common.c:201
 __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
 syscall_exit_to_user_mode+0x19/0x50 kernel/entry/common.c:302
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45e229
Code: Unable to access opcode bytes at RIP 0x45e1ff.
RSP: 002b:00007f2f8ae53cf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: 0000000000000001 RBX: 000000000119c030 RCX: 000000000045e229
RDX: 00000000000f4240 RSI: 0000000000000081 RDI: 000000000119c034
RBP: 000000000119c028 R08: 000000000000000e R09: 0000000000000000
R10: 0000000000000040 R11: 0000000000000246 R12: 000000000119c034
R13: 00007fffb9d4ee7f R14: 00007f2f8ae549c0 R15: 000000000119c034


---
This report 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 syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Re: [syzbot] WARNING in cm109_urb_irq_callback/usb_submit_urb

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:    2d743660 Merge branch 'fixes' of git://git.kernel.org/pub/..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1548f46ad00000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f91155ccddaf919c
dashboard link: https://syzkaller.appspot.com/bug?extid=2d6d691af5ab4b7e66df
compiler:       Debian clang version 11.0.1-2
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11d6cc96d00000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=142de07ed00000

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

cm109 3-1:0.0: cm109_urb_irq_callback: urb status -71
------------[ cut here ]------------
URB 000000003185a218 submitted while active
WARNING: CPU: 0 PID: 8764 at drivers/usb/core/urb.c:378 usb_submit_urb+0xf7f/0x1550 drivers/usb/core/urb.c:378
Modules linked in:
CPU: 0 PID: 8764 Comm: systemd-udevd Not tainted 5.12.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:usb_submit_urb+0xf7f/0x1550 drivers/usb/core/urb.c:378
Code: 5c 41 5d 41 5e 41 5f 5d e9 4e 5b ff ff e8 39 a0 fc fb c6 05 b4 45 25 08 01 48 c7 c7 e0 6e 5f 8a 4c 89 e6 31 c0 e8 81 84 cb fb <0f> 0b e9 f8 f0 ff ff e8 15 a0 fc fb eb 05 e8 0e a0 fc fb bb a6 ff
RSP: 0018:ffffc900000079a8 EFLAGS: 00010046
RAX: 300ec5186f788100 RBX: ffff888020ad2508 RCX: ffff88803054d4c0
RDX: 0000000000000101 RSI: 0000000000000101 RDI: 0000000000000000
RBP: 0000000000000a20 R08: ffffffff8160b632 R09: ffffed1017383f1c
R10: ffffed1017383f1c R11: 0000000000000000 R12: ffff888020ad2500
R13: dffffc0000000000 R14: dffffc0000000000 R15: 0000000000000082
FS:  00007f65b13318c0(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffda12b4ff8 CR3: 0000000020ed4000 CR4: 00000000001506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <IRQ>
 cm109_urb_irq_callback+0x693/0xbf0 drivers/input/misc/cm109.c:422
 __usb_hcd_giveback_urb+0x375/0x520 drivers/usb/core/hcd.c:1656
 dummy_timer+0xa22/0x2e70 drivers/usb/gadget/udc/dummy_hcd.c:1971
 call_timer_fn+0x91/0x160 kernel/time/timer.c:1431
 expire_timers kernel/time/timer.c:1476 [inline]
 __run_timers+0x6c0/0x8a0 kernel/time/timer.c:1745
 run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1758
 __do_softirq+0x318/0x714 kernel/softirq.c:345
 invoke_softirq kernel/softirq.c:221 [inline]
 __irq_exit_rcu+0x1d8/0x200 kernel/softirq.c:422
 irq_exit_rcu+0x5/0x20 kernel/softirq.c:434
 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1100
 </IRQ>
 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:632
RIP: 0010:tomoyo_check_acl+0xb1/0x430 security/tomoyo/domain.c:173
Code: 85 05 03 00 00 48 8b 1c 24 4c 8b 23 49 39 dc 0f 84 14 02 00 00 0f 1f 40 00 49 8d 6c 24 18 48 89 e8 48 c1 e8 03 42 0f b6 04 28 <84> c0 0f 85 1d 01 00 00 0f b6 6d 00 31 ff 89 ee e8 4a df d8 fd 85
RSP: 0018:ffffc9000276fbb8 EFLAGS: 00000a02
RAX: 0000000000000000 RBX: ffff888011bcec90 RCX: ffff88803054d4c0
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002
RBP: ffff888013c51118 R08: ffffffff83a03cb6 R09: ffffffff83a09b20
R10: 0000000000000003 R11: ffff88803054d4c0 R12: ffff888013c51100
R13: dffffc0000000000 R14: ffff888011bcec80 R15: 0000000000000000
 tomoyo_path_permission+0x1af/0x370 security/tomoyo/file.c:586
 tomoyo_path_perm+0x32f/0x570 security/tomoyo/file.c:838
 security_inode_getattr+0xc0/0x140 security/security.c:1288
 vfs_getattr fs/stat.c:131 [inline]
 vfs_statx+0xe8/0x320 fs/stat.c:199
 vfs_fstatat fs/stat.c:217 [inline]
 vfs_lstat include/linux/fs.h:3240 [inline]
 __do_sys_newlstat fs/stat.c:372 [inline]
 __se_sys_newlstat fs/stat.c:366 [inline]
 __x64_sys_newlstat+0x81/0xd0 fs/stat.c:366
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f65b01a3335
Code: 69 db 2b 00 64 c7 00 16 00 00 00 b8 ff ff ff ff c3 0f 1f 40 00 83 ff 01 48 89 f0 77 30 48 89 c7 48 89 d6 b8 06 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 03 f3 c3 90 48 8b 15 31 db 2b 00 f7 d8 64 89
RSP: 002b:00007ffda12b2c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000006
RAX: ffffffffffffffda RBX: 000055b4a2eaa170 RCX: 00007f65b01a3335
RDX: 00007ffda12b2cb0 RSI: 00007ffda12b2cb0 RDI: 000055b4a2ea9170
RBP: 00007ffda12b2d70 R08: 00007f65b0462218 R09: 0000000000001010
R10: 00000000000001a0 R11: 0000000000000246 R12: 000055b4a2ea9170
R13: 000055b4a2ea9191 R14: 000055b4a2eb1fd6 R15: 000055b4a2eb1fe1

WARNING in cm109_urb_irq_callback/usb_submit_urb

[白烁冉]

Dear Maintainers,

When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash (94th)was triggered.


HEAD commit: 6537cfb395f352782918d8ee7b7f10ba2cc3cbf2
git tree: upstream
Output:https://github.com/pghk13/Kernel-Bug/tree/main/0305_6.14rc5/94-INFO_%20rcu%20detected%20stall%20in%20dcache_dir_open
Kernel config:https://github.com/pghk13/Kernel-Bug/blob/main/0305_6.14rc5/config.txt
C reproducer:https://github.com/pghk13/Kernel-Bug/blob/main/0305_6.14rc5/94-INFO_%20rcu%20detected%20stall%20in%20dcache_dir_open/94repro.c
Syzlang reproducer: https://github.com/pghk13/Kernel-Bug/blob/main/0305_6.14rc5/94-INFO_%20rcu%20detected%20stall%20in%20dcache_dir_open/94report


The error occurs around line 379 of the urb.c file. The problem ends up in the cm109_urb_irq_callback function in the cm109.c file:In the cm109_urb_irq_callback function, the driver attempts to resubmit a URB that has not yet been processed. There may be a race condition in the driver that resubmits the URB in the URB completion callback, but the same URB may have already been committed to another location in the system. This issue seems to involve the creation of USB devices, the operation of TTY devices, and file descriptor copying. This complex interaction resulted in duplicate commits of the URB.
We have reproduced this issue several times on 6.14-rc5 again.




If you fix this issue, please add the following tag to the commit:
Reported-by: Kun Hu <huk23@m.fudan.edu.cn>, Jiaji Qin <jjtan24@m.fudan.edu.cn>, Shuoran Bai <baishuoran@hrbeu.edu.cn>


================================================================== 
URB ffff888045c81800 submitted while active
WARNING: CPU: 0 PID: 0 at drivers/usb/core/urb.c:379 usb_submit_urb+0x134e/0x1750
Modules linked in:
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.14.0-rc5 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:usb_submit_urb+0x134e/0x1750
Code: e8 c7 b4 a0 fa 84 db 0f 85 47 f5 ff ff e8 0a b3 a0 fa c6 05 c3 ba 30 09 01 90 48 c7 c7 00 3e 2f 8c 4c 89 fe e8 e3 a8 60 fa 90 <0f> 0b 90 90 e9 21 f5 ff ff 48 89 7c 24 38 e8 df b2 a0 fa 48 8b 7c
RSP: 0018:ffffc90000007ad0 EFLAGS: 00010082
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8179ec7a
RDX: 0000000000000000 RSI: ffffffff8de97740 RDI: 0000000000000002
RBP: ffff888022bee740 R08: 0000000000000000 R09: ffffed1005705182
R10: ffffed1005705181 R11: ffff88802b828c0b R12: 0000000000000046
R13: ffff888027b24058 R14: 00000000fffffff0 R15: ffff888045c81800
FS:  0000000000000000(0000) GS:ffff88802b800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fffca04ff60 CR3: 000000000df80000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
 <IRQ>
 cm109_urb_irq_callback+0x44b/0xb60
 __usb_hcd_giveback_urb+0x2e4/0x6b0
 usb_hcd_giveback_urb+0x391/0x450
 dummy_timer+0x1217/0x3540
 __hrtimer_run_queues+0x1b7/0xc30
 hrtimer_run_softirq+0x17f/0x2e0
 handle_softirqs+0x1bd/0x880
 irq_exit_rcu+0xfd/0x150
 sysvec_apic_timer_interrupt+0xa8/0xc0
 </IRQ>
 <TASK>
 asm_sysvec_apic_timer_interrupt+0x1a/0x20
RIP: 0010:default_idle+0x1e/0x30
Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 eb 0c 0f 1f 44 00 00 0f 00 2d c9 a9 0d 00 0f 1f 44 00 00 fb f4 <fa> e9 a7 41 b7 f5 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90
RSP: 0018:ffffffff8de07e08 EFLAGS: 00000206
RAX: 000000000027dec5 RBX: 0000000000000000 RCX: ffffffff8b58e5a7
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: dffffc0000000000 R08: 0000000000000001 R09: ffffed1005706f86
R10: ffffed1005706f85 R11: ffff88802b837c2b R12: 0000000000000000
R13: ffffffff90616a10 R14: 0000000000000000 R15: 0000000000000000
 default_idle_call+0x6d/0xb0
 do_idle+0x312/0x3c0
 cpu_startup_entry+0x4f/0x60
 rest_init+0x1a9/0x2f0
 start_kernel+0x3fa/0x4e0
 x86_64_start_reservations+0x18/0x30
 x86_64_start_kernel+0xb3/0xc0
 common_startup_64+0x13e/0x148
 </TASK>
--------------------------------
Code disassembly (best guess):
   0:	90                   	nop
   1:	90                   	nop
   2:	90                   	nop
   3:	90                   	nop
   4:	90                   	nop
   5:	90                   	nop
   6:	90                   	nop
   7:	90                   	nop
   8:	90                   	nop
   9:	90                   	nop
   a:	90                   	nop
   b:	90                   	nop
   c:	f3 0f 1e fa          	endbr64
  10:	0f 1f 44 00 00       	nopl   0x0(%rax,%rax,1)
  15:	eb 0c                	jmp    0x23
  17:	0f 1f 44 00 00       	nopl   0x0(%rax,%rax,1)
  1c:	0f 00 2d c9 a9 0d 00 	verw   0xda9c9(%rip)        # 0xda9ec
  23:	0f 1f 44 00 00       	nopl   0x0(%rax,%rax,1)
  28:	fb                   	sti
  29:	f4                   	hlt
* 2a:	fa                   	cli <-- trapping instruction
  2b:	e9 a7 41 b7 f5       	jmpq   0xf5b741d7
  30:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
  37:	00 00 00 00
  3b:	90                   	nop
  3c:	90                   	nop
  3d:	90                   	nop
  3e:	90                   	nop
  3f:	90                   	nop
--------------------------------





thanks,
Kun Hu

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[Oliver Neukum]

[-- Attachment #1: Type: text/plain, Size: 258 bytes --]



On 20.03.25 05:39, 白烁冉 wrote:
> Dear Maintainers,
> 
> When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash (94th)was triggered.
> 

Hi,

is there a way to use the syzkaller for testing a patch?

	Regards
		Oliver

[-- Attachment #2: 0001-USB-cm109-fix-race-between-restarting-and-close.patch --]
[-- Type: text/x-patch, Size: 908 bytes --]

From 03d78ca8c47c8c888df7c7ae2c7109825799d236 Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum@suse.com>
Date: Thu, 20 Mar 2025 14:29:17 +0100
Subject: [PATCH] USB: cm109: fix race between restarting and close

cm109_input_close() can race with cm109_restore_state()
Hence cm109_submit_buzz_toggle() needs to check
the shutdown flag

Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
 drivers/input/misc/cm109.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/input/misc/cm109.c b/drivers/input/misc/cm109.c
index 0cfe5d4a573c..8ae62b5e45f6 100644
--- a/drivers/input/misc/cm109.c
+++ b/drivers/input/misc/cm109.c
@@ -348,6 +348,8 @@ static void cm109_submit_buzz_toggle(struct cm109_dev *dev)
 	else
 		dev->ctl_data->byte[HID_OR0] &= ~BUZZER_ON;
 
+	if (dev->shutdown)
+		return;
 	error = usb_submit_urb(dev->urb_ctl, GFP_ATOMIC);
 	if (error)
 		dev_err(&dev->intf->dev,
-- 
2.48.1

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[Greg Kroah-Hartman]

On Thu, Mar 20, 2025 at 12:39:24PM +0800, 白烁冉 wrote:
> Dear Maintainers,
> 
> When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash (94th)was triggered.
> 
> 
> HEAD commit: 6537cfb395f352782918d8ee7b7f10ba2cc3cbf2
> git tree: upstream
> Output:https://github.com/pghk13/Kernel-Bug/tree/main/0305_6.14rc5/94-INFO_%20rcu%20detected%20stall%20in%20dcache_dir_open
> Kernel config:https://github.com/pghk13/Kernel-Bug/blob/main/0305_6.14rc5/config.txt
> C reproducer:https://github.com/pghk13/Kernel-Bug/blob/main/0305_6.14rc5/94-INFO_%20rcu%20detected%20stall%20in%20dcache_dir_open/94repro.c
> Syzlang reproducer: https://github.com/pghk13/Kernel-Bug/blob/main/0305_6.14rc5/94-INFO_%20rcu%20detected%20stall%20in%20dcache_dir_open/94report
> 
> 
> The error occurs around line 379 of the urb.c file. The problem ends up in the cm109_urb_irq_callback function in the cm109.c file:In the cm109_urb_irq_callback function, the driver attempts to resubmit a URB that has not yet been processed. There may be a race condition in the driver that resubmits the URB in the URB completion callback, but the same URB may have already been committed to another location in the system. This issue seems to involve the creation of USB devices, the operation of TTY devices, and file descriptor copying. This complex interaction resulted in duplicate commits of the URB.
> We have reproduced this issue several times on 6.14-rc5 again.

Great!  Can you submit a fix for this as you have a reproducer you can
use to prove that it resolves the issue?

thanks,

greg k-h

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[胡焜]

> 2025年3月20日 21:35，Oliver Neukum <oneukum@suse.com> 写道：
> 
> 
> On 20.03.25 05:39, 白烁冉 wrote:
>> Dear Maintainers,
>> When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash (94th)was triggered.
> 
> Hi,
> 
> is there a way to use the syzkaller for testing a patch?
> 
> Regards
> Oliver
> <0001-USB-cm109-fix-race-between-restarting-and-close.patch>


Thanks,

I’ll test the patch for multiple rounds to check if it works.

Best,
Kun

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[Alan Stern]

On Thu, Mar 20, 2025 at 02:35:23PM +0100, Oliver Neukum wrote:
> 
> 
> On 20.03.25 05:39, 白烁冉 wrote:
> > Dear Maintainers,
> > 
> > When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash (94th)was triggered.
> > 
> 
> Hi,
> 
> is there a way to use the syzkaller for testing a patch?
> 
> 	Regards
> 		Oliver

> From 03d78ca8c47c8c888df7c7ae2c7109825799d236 Mon Sep 17 00:00:00 2001
> From: Oliver Neukum <oneukum@suse.com>
> Date: Thu, 20 Mar 2025 14:29:17 +0100
> Subject: [PATCH] USB: cm109: fix race between restarting and close
> 
> cm109_input_close() can race with cm109_restore_state()
> Hence cm109_submit_buzz_toggle() needs to check
> the shutdown flag
> 
> Signed-off-by: Oliver Neukum <oneukum@suse.com>
> ---
>  drivers/input/misc/cm109.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/input/misc/cm109.c b/drivers/input/misc/cm109.c
> index 0cfe5d4a573c..8ae62b5e45f6 100644
> --- a/drivers/input/misc/cm109.c
> +++ b/drivers/input/misc/cm109.c
> @@ -348,6 +348,8 @@ static void cm109_submit_buzz_toggle(struct cm109_dev *dev)
>  	else
>  		dev->ctl_data->byte[HID_OR0] &= ~BUZZER_ON;
>  
> +	if (dev->shutdown)
> +		return;

This test must itself be subject to the same race, right?  There needs 
to be some kind of synchronization between the two tasks (i.e., a mutex, 
spinlock, or something similar).

Alan Stern

>  	error = usb_submit_urb(dev->urb_ctl, GFP_ATOMIC);
>  	if (error)
>  		dev_err(&dev->intf->dev,
> -- 
> 2.48.1

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[Oliver Neukum]

On 20.03.25 15:25, Alan Stern wrote:

> This test must itself be subject to the same race, right?  There needs
> to be some kind of synchronization between the two tasks (i.e., a mutex,
> spinlock, or something similar).

Hi,

there is:

static void cm109_stop_traffic(struct cm109_dev *dev)
{
         dev->shutdown = 1;
         /*
          * Make sure other CPUs see this
          */
         smp_wmb();
                 
         usb_kill_urb(dev->urb_ctl);
         usb_kill_urb(dev->urb_irq);
                 
         cm109_toggle_buzzer_sync(dev, 0);
                 
         dev->shutdown = 0;
         smp_wmb();
}

This driver has a tough job as the two completion
handlers submitted each other's as well as their own
URBs based on the data they get.
That scheme is rather complex, but as far as I can tell correct,
but you need to test that flag everywhere.

	Regards
		Oliver
           

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[Alan Stern]

On Thu, Mar 20, 2025 at 04:42:33PM +0100, Oliver Neukum wrote:
> On 20.03.25 15:25, Alan Stern wrote:
> 
> > This test must itself be subject to the same race, right?  There needs
> > to be some kind of synchronization between the two tasks (i.e., a mutex,
> > spinlock, or something similar).
> 
> Hi,
> 
> there is:
> 
> static void cm109_stop_traffic(struct cm109_dev *dev)
> {
>         dev->shutdown = 1;
>         /*
>          * Make sure other CPUs see this
>          */
>         smp_wmb();
>         usb_kill_urb(dev->urb_ctl);
>         usb_kill_urb(dev->urb_irq);
>         cm109_toggle_buzzer_sync(dev, 0);
>         dev->shutdown = 0;
>         smp_wmb();

I don't know anything about this driver, but the placement of the second 
smp_wmb() looks odd.  Should it really come before the line that sets 
dev->shutdown to 0?  In general, smp_wmb() is used to separate two sets 
of stores; if it comes after all the relevant stores have been performed 
then it won't accomplish anything.

> }
> 
> This driver has a tough job as the two completion
> handlers submitted each other's as well as their own
> URBs based on the data they get.
> That scheme is rather complex, but as far as I can tell correct,
> but you need to test that flag everywhere.

However, it's quite noticeable that the code you want to change in 
cm109_submit_buzz_toggle() doesn't have any memory barriers to pair with 
the smb_wmb()'s above.  Shouldn't there at least be an smp_rmb() after 
you read dev->shutdown?

As long you're updating the synchronization, it might be a good idea to 
also improve the comment describing the memory barriers.  "Make sure 
other CPUs see this" doesn't mean anything -- of course all the other 
CPUs will eventually see the changes made here.  The point is that they 
should see the new value of dev->shutdown before seeing the final 
completion of the two URBs.  Also, the comment should say which other 
memory barriers pair with the ones here.

Alan Stern

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[Oliver Neukum]

Hi,

On 20.03.25 18:25, Alan Stern wrote:

>> static void cm109_stop_traffic(struct cm109_dev *dev)
>> {
>>          dev->shutdown = 1;
>>          /*
>>           * Make sure other CPUs see this
>>           */
>>          smp_wmb();
>>          usb_kill_urb(dev->urb_ctl);
>>          usb_kill_urb(dev->urb_irq);
>>          cm109_toggle_buzzer_sync(dev, 0);
>>          dev->shutdown = 0;
>>          smp_wmb();
> 
> I don't know anything about this driver, but the placement of the second
> smp_wmb() looks odd.  Should it really come before the line that sets

Indeed. This driver is not written for comprehension. As far as I can tell
it is not necessary at all. You need to set shutdown to zero before you
resubmit the URBs. But I don't see how the barrier helps with that.

> dev->shutdown to 0?  In general, smp_wmb() is used to separate two sets
> of stores; if it comes after all the relevant stores have been performed
> then it won't accomplish anything.

Don't we guarantee an interaction between smp_wmb() and taking a spinlock?
> 
>> }
>>
>> This driver has a tough job as the two completion
>> handlers submitted each other's as well as their own
>> URBs based on the data they get.
>> That scheme is rather complex, but as far as I can tell correct,
>> but you need to test that flag everywhere.
> 
> However, it's quite noticeable that the code you want to change in
> cm109_submit_buzz_toggle() doesn't have any memory barriers to pair with
> the smb_wmb()'s above.  Shouldn't there at least be an smp_rmb() after
> you read dev->shutdown?

I think this driver assumes that the ctl_submit_lock spinlock makes
it safe.

> As long you're updating the synchronization, it might be a good idea to
> also improve the comment describing the memory barriers.  "Make sure
> other CPUs see this" doesn't mean anything -- of course all the other
> CPUs will eventually see the changes made here.  The point is that they
> should see the new value of dev->shutdown before seeing the final
> completion of the two URBs.  Also, the comment should say which other
> memory barriers pair with the ones here.

Before the completion? AFAICT they need to see it before they try
to submit an URB.

	Regards
		Oliver

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[Alan Stern]

On Thu, Mar 27, 2025 at 12:42:41PM +0100, Oliver Neukum wrote:
> Hi,
> 
> On 20.03.25 18:25, Alan Stern wrote:
> 
> > > static void cm109_stop_traffic(struct cm109_dev *dev)
> > > {
> > >          dev->shutdown = 1;
> > >          /*
> > >           * Make sure other CPUs see this
> > >           */
> > >          smp_wmb();
> > >          usb_kill_urb(dev->urb_ctl);
> > >          usb_kill_urb(dev->urb_irq);
> > >          cm109_toggle_buzzer_sync(dev, 0);
> > >          dev->shutdown = 0;
> > >          smp_wmb();
> > 
> > I don't know anything about this driver, but the placement of the second
> > smp_wmb() looks odd.  Should it really come before the line that sets
> 
> Indeed. This driver is not written for comprehension. As far as I can tell
> it is not necessary at all. You need to set shutdown to zero before you
> resubmit the URBs. But I don't see how the barrier helps with that.
> 
> > dev->shutdown to 0?  In general, smp_wmb() is used to separate two sets
> > of stores; if it comes after all the relevant stores have been performed
> > then it won't accomplish anything.
> 
> Don't we guarantee an interaction between smp_wmb() and taking a spinlock?

There's no special interaction between them.  Just the usual ordering 
requirement between the smp_wmb() memory barrier and the write part of 
a spin_lock() or spin_unlock().

> > > }
> > > 
> > > This driver has a tough job as the two completion
> > > handlers submitted each other's as well as their own
> > > URBs based on the data they get.
> > > That scheme is rather complex, but as far as I can tell correct,
> > > but you need to test that flag everywhere.
> > 
> > However, it's quite noticeable that the code you want to change in
> > cm109_submit_buzz_toggle() doesn't have any memory barriers to pair with
> > the smb_wmb()'s above.  Shouldn't there at least be an smp_rmb() after
> > you read dev->shutdown?
> 
> I think this driver assumes that the ctl_submit_lock spinlock makes
> it safe.

I haven't looked at the code, but it sounds like a quick audit might be 
in order.

> > As long you're updating the synchronization, it might be a good idea to
> > also improve the comment describing the memory barriers.  "Make sure
> > other CPUs see this" doesn't mean anything -- of course all the other
> > CPUs will eventually see the changes made here.  The point is that they
> > should see the new value of dev->shutdown before seeing the final
> > completion of the two URBs.  Also, the comment should say which other
> > memory barriers pair with the ones here.
> 
> Before the completion? AFAICT they need to see it before they try
> to submit an URB.

My point was that the memory barrier doesn't "make sure other CPUs will 
see this", as the command says.  Rather, it provides ordering: It 
ensures that other CPUs will see the writes preceding the memory barrier 
before they see the writes following the memory barrier.

Hence the comment should be updated, so that it provides information 
that actually is important for someone reading the code to know.

Alan Stern

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[胡焜]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]



> 2025年3月20日 21:35，Oliver Neukum <oneukum@suse.com> 写道：
> 
> 
> On 20.03.25 05:39, 白烁冉 wrote:
>> Dear Maintainers,
>> When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash (94th)was triggered.
> 
> Hi,
> 
> is there a way to use the syzkaller for testing a patch?
> 
> Regards
> Oliver
> <0001-USB-cm109-fix-race-between-restarting-and-close.patch>


Hi Oliver,

Sorry for late, our servers have been down for a few days and we just managed to fix it today.

We retested the patch you provided, but we found that the issue still exists, but may be somewhat different from the call trace from the previous issue. I have provided a screenshot in diff form and the full call trace log in the attachment.


——————
Thanks,
Kun Hu


[-- Attachment #2: call trace.txt --]
[-- Type: text/plain, Size: 17832 bytes --]

[  205.291977][    C1] cm109 2-1:0.8: cm109_urb_irq_callback: urb status -71
[  205.294340][    C1] ------------[ cut here ]------------
[  205.294371][    C1] URB ffff888046212a00 submitted while active
[  205.298576][   T31] usb 2-1: USB disconnect, device number 2
[  205.296207][    C1] WARNING: CPU: 1 PID: 13 at drivers/usb/core/urb.c:379 usb_submit_urb+0x134e/0x1750
[  205.296207][    C1] Modules linked in:
[  205.296207][    C1] CPU: 1 UID: 0 PID: 13 Comm: kworker/u16:1 Not tainted 6.14.0 #2
[  205.296207][    C1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
[  205.296207][    C1] Workqueue: ipv6_addrconf addrconf_dad_work
[  205.296207][    C1] RIP: 0010:usb_submit_urb+0x134e/0x1750
[  205.296207][    C1] Code: e8 07 19 a0 fa 84 db 0f 85 47 f5 ff ff e8 4a 17 a0 fa c6 05 cd 05 30 09 01 90 48 c7 c7 00 4f 2f 8c 4c 89 fe e8 43 11 60 fa 90 <0f> 0b 90 90 e9 21 f5 ff ff 48 89 7c 24 38 e8 1f 17 a0 fa 48 8b 7c
[  205.296207][    C1] RSP: 0018:ffffc900001f8ae0 EFLAGS: 00010082
[  205.296207][    C1] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817a1c9a
[  205.296207][    C1] RDX: 0000000000000000 RSI: ffff88801d2a8000 RDI: 0000000000000002
[  205.296207][    C1] RBP: ffff8880664cdb20 R08: 0000000000000000 R09: ffffed100fdc5182
[  205.296207][    C1] R10: ffffed100fdc5181 R11: ffff88807ee28c0b R12: 0000000000000046
[  205.296207][    C1] R13: ffff888055310858 R14: 00000000fffffff0 R15: ffff888046212a00
[  205.296207][    C1] FS:  0000000000000000(0000) GS:ffff88807ee00000(0000) knlGS:0000000000000000
[  205.329719][    C1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  205.329719][    C1] CR2: 00007f4d8afa7bac CR3: 000000004c5aa000 CR4: 0000000000750ef0
[  205.329719][    C1] PKRU: 55555554
[  205.329719][    C1] Call Trace:
[  205.329719][    C1]  <IRQ>
[  205.329719][    C1]  ? __warn+0xea/0x3d0
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? usb_submit_urb+0x134e/0x1750
[  205.329719][    C1]  ? report_bug+0x367/0x5c0
[  205.329719][    C1]  ? usb_submit_urb+0x134e/0x1750
[  205.329719][    C1]  ? usb_submit_urb+0x134f/0x1750
[  205.344531][  T111] usb 4-1: new high-speed USB device number 2 using dummy_hcd
[  205.329719][    C1]  ? handle_bug+0xec/0x180
[  205.329719][    C1]  ? exc_invalid_op+0x35/0x80
[  205.329719][    C1]  ? asm_exc_invalid_op+0x1a/0x20
[  205.329719][    C1]  ? __warn_printk+0x17a/0x310
[  205.329719][    C1]  ? usb_submit_urb+0x134e/0x1750
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  cm109_urb_irq_callback+0x44b/0xb60
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  __usb_hcd_giveback_urb+0x2e4/0x6b0
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  usb_hcd_giveback_urb+0x391/0x450
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  dummy_timer+0x1217/0x3540
[  205.329719][    C1]  ? debug_object_deactivate+0x2af/0x390
[  205.329719][    C1]  ? __pfx_mark_lock+0x10/0x10
[  205.329719][    C1]  ? find_held_lock+0x2d/0x120
[  205.329719][    C1]  ? __hrtimer_run_queues+0x529/0xc30
[  205.329719][    C1]  ? __pfx_dummy_timer+0x10/0x10
[  205.329719][    C1]  ? __pfx_dummy_timer+0x10/0x10
[  205.329719][    C1]  ? _raw_spin_unlock_irqrestore+0x58/0x70
[  205.329719][    C1]  ? _raw_spin_unlock_irqrestore+0x58/0x70
[  205.329719][    C1]  ? __pfx_dummy_timer+0x10/0x10
[  205.329719][    C1]  __hrtimer_run_queues+0x1b7/0xc30
[  205.329719][    C1]  ? __pfx___hrtimer_run_queues+0x10/0x10
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  hrtimer_run_softirq+0x17f/0x2e0
[  205.329719][    C1]  handle_softirqs+0x1bd/0x880
[  205.329719][    C1]  ? __dev_queue_xmit+0x1984/0x4060
[  205.329719][    C1]  do_softirq.part.0+0x8f/0xd0
[  205.329719][    C1]  </IRQ>
[  205.329719][    C1]  <TASK>
[  205.329719][    C1]  __local_bh_enable_ip+0x10e/0x130
[  205.329719][    C1]  ? __dev_queue_xmit+0x1984/0x4060
[  205.329719][    C1]  __dev_queue_xmit+0x1999/0x4060
[  205.329719][    C1]  ? __pfx___dev_queue_xmit+0x10/0x10
[  205.329719][    C1]  ? mark_lock+0xfe/0x12c0
[  205.329719][    C1]  ? __pfx_mark_lock+0x10/0x10
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? find_held_lock+0x2d/0x120
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? eth_header+0x118/0x1f0
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? macvlan_hard_header+0xe1/0x160
[  205.329719][    C1]  neigh_resolve_output+0x527/0x8f0
[  205.329719][    C1]  ip6_finish_output2+0xb2b/0x22f0
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __pfx_ip6_finish_output2+0x10/0x10
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? find_held_lock+0x2d/0x120
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ip6_finish_output+0x71a/0x1220
[  205.329719][    C1]  ip6_output+0x253/0x8e0
[  205.329719][    C1]  ? __pfx_ip6_output+0x10/0x10
[  205.329719][    C1]  ? ndisc_send_skb+0x58c/0x1a40
[  205.329719][    C1]  ? lockdep_rcu_suspicious+0x214/0x380
[  205.329719][    C1]  ? __pfx_ip6_finish_output+0x10/0x10
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? write_comp_data+0x29/0x80
[  205.329719][    C1]  ? __pfx_ip6_output+0x10/0x10
[  205.329719][    C1]  ndisc_send_skb+0xdce/0x1a40
[  205.329719][    C1]  ? __pfx_ndisc_send_skb+0x10/0x10
[  205.329719][    C1]  ? ndisc_alloc_skb+0x328/0x540
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? write_comp_data+0x29/0x80
[  205.329719][    C1]  ndisc_send_rs+0x12d/0x6d0
[  205.329719][    C1]  addrconf_dad_completed+0x438/0xdb0
[  205.329719][    C1]  ? __pfx_addrconf_dad_completed+0x10/0x10
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __local_bh_enable_ip+0xa4/0x130
[  205.329719][    C1]  ? addrconf_dad_work+0x830/0x1530
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  addrconf_dad_work+0x830/0x1530
[  205.329719][    C1]  ? __pfx_addrconf_dad_work+0x10/0x10
[  205.329719][    C1]  ? write_comp_data+0x29/0x80
[  205.329719][    C1]  ? _raw_spin_unlock_irq+0x23/0x50
[  205.329719][    C1]  ? _raw_spin_unlock_irq+0x23/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  process_scheduled_works+0x5c0/0x1aa0
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __pfx_process_scheduled_works+0x10/0x10
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? assign_work+0x195/0x240
[  205.329719][    C1]  worker_thread+0x59f/0xcf0
[  205.329719][    C1]  ? __pfx_worker_thread+0x10/0x10
[  205.329719][    C1]  kthread+0x42a/0x880
[  205.329719][    C1]  ? __pfx_kthread+0x10/0x10
[  205.329719][    C1]  ? write_comp_data+0x29/0x80
[  205.329719][    C1]  ? _raw_spin_unlock_irq+0x23/0x50
[  205.329719][    C1]  ? _raw_spin_unlock_irq+0x23/0x50
[  205.329719][    C1]  ? __pfx_kthread+0x10/0x10
[  205.329719][    C1]  ret_from_fork+0x48/0x80
[  205.329719][    C1]  ? __pfx_kthread+0x10/0x10
[  205.329719][    C1]  ret_from_fork_asm+0x1a/0x30
[  205.329719][    C1]  </TASK>
[  205.329719][    C1] Kernel panic - not syncing: kernel: panic_on_warn set ...
[  205.329719][    C1] CPU: 1 UID: 0 PID: 13 Comm: kworker/u16:1 Not tainted 6.14.0 #2
[  205.329719][    C1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
[  205.329719][    C1] Workqueue: ipv6_addrconf addrconf_dad_work
[  205.329719][    C1] Call Trace:
[  205.329719][    C1]  <IRQ>
[  205.329719][    C1]  dump_stack_lvl+0x3d/0x1b0
[  205.329719][    C1]  panic+0x70b/0x7c0
[  205.329719][    C1]  ? __pfx_panic+0x10/0x10
[  205.329719][    C1]  ? show_trace_log_lvl+0x284/0x390
[  205.329719][    C1]  ? check_panic_on_warn+0x1f/0xc0
[  205.329719][    C1]  ? usb_submit_urb+0x134e/0x1750
[  205.329719][    C1]  check_panic_on_warn+0xb1/0xc0
[  205.329719][    C1]  __warn+0xf6/0x3d0
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? usb_submit_urb+0x134e/0x1750
[  205.329719][    C1]  report_bug+0x367/0x5c0
[  205.329719][    C1]  ? usb_submit_urb+0x134e/0x1750
[  205.329719][    C1]  ? usb_submit_urb+0x134f/0x1750
[  205.329719][    C1]  handle_bug+0xec/0x180
[  205.329719][    C1]  exc_invalid_op+0x35/0x80
[  205.329719][    C1]  asm_exc_invalid_op+0x1a/0x20
[  205.329719][    C1] RIP: 0010:usb_submit_urb+0x134e/0x1750
[  205.329719][    C1] Code: e8 07 19 a0 fa 84 db 0f 85 47 f5 ff ff e8 4a 17 a0 fa c6 05 cd 05 30 09 01 90 48 c7 c7 00 4f 2f 8c 4c 89 fe e8 43 11 60 fa 90 <0f> 0b 90 90 e9 21 f5 ff ff 48 89 7c 24 38 e8 1f 17 a0 fa 48 8b 7c
[  205.329719][    C1] RSP: 0018:ffffc900001f8ae0 EFLAGS: 00010082
[  205.329719][    C1] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817a1c9a
[  205.329719][    C1] RDX: 0000000000000000 RSI: ffff88801d2a8000 RDI: 0000000000000002
[  205.329719][    C1] RBP: ffff8880664cdb20 R08: 0000000000000000 R09: ffffed100fdc5182
[  205.329719][    C1] R10: ffffed100fdc5181 R11: ffff88807ee28c0b R12: 0000000000000046
[  205.329719][    C1] R13: ffff888055310858 R14: 00000000fffffff0 R15: ffff888046212a00
[  205.329719][    C1]  ? __warn_printk+0x17a/0x310
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  cm109_urb_irq_callback+0x44b/0xb60
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  __usb_hcd_giveback_urb+0x2e4/0x6b0
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  usb_hcd_giveback_urb+0x391/0x450
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  dummy_timer+0x1217/0x3540
[  205.329719][    C1]  ? debug_object_deactivate+0x2af/0x390
[  205.329719][    C1]  ? __pfx_mark_lock+0x10/0x10
[  205.329719][    C1]  ? find_held_lock+0x2d/0x120
[  205.329719][    C1]  ? __hrtimer_run_queues+0x529/0xc30
[  205.329719][    C1]  ? __pfx_dummy_timer+0x10/0x10
[  205.329719][    C1]  ? __pfx_dummy_timer+0x10/0x10
[  205.329719][    C1]  ? _raw_spin_unlock_irqrestore+0x58/0x70
[  205.329719][    C1]  ? _raw_spin_unlock_irqrestore+0x58/0x70
[  205.329719][    C1]  ? __pfx_dummy_timer+0x10/0x10
[  205.329719][    C1]  __hrtimer_run_queues+0x1b7/0xc30
[  205.329719][    C1]  ? __pfx___hrtimer_run_queues+0x10/0x10
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  hrtimer_run_softirq+0x17f/0x2e0
[  205.329719][    C1]  handle_softirqs+0x1bd/0x880
[  205.329719][    C1]  ? __dev_queue_xmit+0x1984/0x4060
[  205.329719][    C1]  do_softirq.part.0+0x8f/0xd0
[  205.329719][    C1]  </IRQ>
[  205.329719][    C1]  <TASK>
[  205.329719][    C1]  __local_bh_enable_ip+0x10e/0x130
[  205.329719][    C1]  ? __dev_queue_xmit+0x1984/0x4060
[  205.329719][    C1]  __dev_queue_xmit+0x1999/0x4060
[  205.329719][    C1]  ? __pfx___dev_queue_xmit+0x10/0x10
[  205.329719][    C1]  ? mark_lock+0xfe/0x12c0
[  205.329719][    C1]  ? __pfx_mark_lock+0x10/0x10
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? find_held_lock+0x2d/0x120
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? eth_header+0x118/0x1f0
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? macvlan_hard_header+0xe1/0x160
[  205.614574][    C1]  neigh_resolve_output+0x527/0x8f0
[  205.614574][    C1]  ip6_finish_output2+0xb2b/0x22f0
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? __pfx_ip6_finish_output2+0x10/0x10
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? find_held_lock+0x2d/0x120
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.614574][    C1]  ip6_finish_output+0x71a/0x1220
[  205.614574][    C1]  ip6_output+0x253/0x8e0
[  205.614574][    C1]  ? __pfx_ip6_output+0x10/0x10
[  205.614574][    C1]  ? ndisc_send_skb+0x58c/0x1a40
[  205.614574][    C1]  ? lockdep_rcu_suspicious+0x214/0x380
[  205.614574][    C1]  ? __pfx_ip6_finish_output+0x10/0x10
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? write_comp_data+0x29/0x80
[  205.614574][    C1]  ? __pfx_ip6_output+0x10/0x10
[  205.614574][    C1]  ndisc_send_skb+0xdce/0x1a40
[  205.614574][    C1]  ? __pfx_ndisc_send_skb+0x10/0x10
[  205.614574][    C1]  ? ndisc_alloc_skb+0x328/0x540
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? write_comp_data+0x29/0x80
[  205.614574][    C1]  ndisc_send_rs+0x12d/0x6d0
[  205.614574][    C1]  addrconf_dad_completed+0x438/0xdb0
[  205.614574][    C1]  ? __pfx_addrconf_dad_completed+0x10/0x10
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? __local_bh_enable_ip+0xa4/0x130
[  205.614574][    C1]  ? addrconf_dad_work+0x830/0x1530
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  addrconf_dad_work+0x830/0x1530
[  205.614574][    C1]  ? __pfx_addrconf_dad_work+0x10/0x10
[  205.614574][    C1]  ? write_comp_data+0x29/0x80
[  205.614574][    C1]  ? _raw_spin_unlock_irq+0x23/0x50
[  205.614574][    C1]  ? _raw_spin_unlock_irq+0x23/0x50
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  process_scheduled_works+0x5c0/0x1aa0
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? __pfx_process_scheduled_works+0x10/0x10
[  205.614574][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? assign_work+0x195/0x240
[  205.614574][    C1]  worker_thread+0x59f/0xcf0
[  205.614574][    C1]  ? __pfx_worker_thread+0x10/0x10
[  205.614574][    C1]  kthread+0x42a/0x880
[  205.614574][    C1]  ? __pfx_kthread+0x10/0x10
[  205.614574][    C1]  ? write_comp_data+0x29/0x80
[  205.614574][    C1]  ? _raw_spin_unlock_irq+0x23/0x50
[  205.614574][    C1]  ? _raw_spin_unlock_irq+0x23/0x50
[  205.614574][    C1]  ? __pfx_kthread+0x10/0x10
[  205.614574][    C1]  ret_from_fork+0x48/0x80
[  205.614574][    C1]  ? __pfx_kthread+0x10/0x10
[  205.614574][    C1]  ret_from_fork_asm+0x1a/0x30
[  205.614574][    C1]  </TASK>
[  205.614574][    C1] Shutting down cpus with NMI
[  205.614574][    C1] Kernel Offset: disabled
[  205.614574][    C1] Rebooting in 86400 seconds..

[-- Attachment #3: diff.jpg --]
[-- Type: image/jpeg, Size: 143791 bytes --]

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[胡焜]

> 
> 
> Hi Oliver,
> 
> Sorry for late, our servers have been down for a few days and we just managed to fix it today.
> 
> We retested the patch you provided, but we found that the issue still exists, but may be somewhat different from the call trace from the previous issue. I have provided a screenshot in diff form and the full call trace log in the attachment.
> 
> 
> ——————
> Thanks,
> Kun Hu
> 
> 
> <call trace.txt><diff.jpg>


Hi Oliver,

Was the information on these tests helpful to you? Please let me know if there are any tests you need.

—————
Best,
Kun