12148d4300
Locking the second lock which causes the LOR, can be skipped because the code updating the shared variables is always executing from the same USB thread. lock order reversal: 1st 0xfffff80005cc3840 pcm7:play:dsp7.p0 (pcm play channel, sleep mutex) @ usb_transfer.c:2342 2nd 0xfffff80005cc3860 pcm7:record:dsp7.r0 (pcm record channel, sleep mutex) @ uaudio.c:2317 lock order pcm record channel -> pcm play channel established at: witness_checkorder+0x461 __mtx_lock_flags+0x98 dsp_mmap_single+0x151 vm_mmap_cdev+0x65 devfs_mmap_f+0x143 kern_mmap_req+0x594 sys_mmap+0x46 amd64_syscall+0x12e fast_syscall_common+0xf8 lock order pcm play channel -> pcm record channel attempted at: witness_checkorder+0xd82 __mtx_lock_flags+0x98 uaudio_chan_play_callback+0xeb usbd_callback_wrapper+0x7ec usb_command_wrapper+0x7e usb_callback_proc+0x8e usb_process+0xf3 fork_exit+0x80 fork_trampoline+0xe Found by: Stefan Ehmann <shoesoft@gmx.net> MFC after: 1 week Sponsored by: Mellanox Technologies // NVIDIA Networking |
||
|---|---|---|
| .. | ||
| uaudio_pcm.c | ||
| uaudio.c | ||
| uaudio.h | ||
| uaudioreg.h | ||