Bug 204087
Summary: | Bad handling of removing a USB device while recording audio from it | ||
---|---|---|---|
Product: | v4l-dvb | Reporter: | Tom Mason (wheybags) |
Component: | v4l-other | Assignee: | v4l-other (v4l-dvb_v4l-other) |
Status: | REOPENED --- | ||
Severity: | normal | CC: | tiwai, zfigura |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 4.19 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | dmesg including backtrace of deadlock |
Description
Tom Mason
2019-07-07 13:11:27 UTC
It's the expected behavior. In Linux kernel, you can't delete the file object from the kernel side while it's in use. The handling of such a situation differs with each driver / subsystem, and for the sound subsystem, we replace the file ops to respond only but closing when a device gets disconnected. So, this behaviour causes pulseaudio to hang if it is using the device while it's pulled. Is this indeed a bug in pulseaudio? Also, this behavior does not occur with a different usb sound card. OK, then it's a bug in that V4L driver. cx231xx is no USB-audio device, but a V4L driver supporting ALSA device, and probably it has no proper disconnection handling for the audio. I try to change the component. You might report to another V4L bug tracking, if this isn't taken. Created attachment 288741 [details]
dmesg including backtrace of deadlock
I encountered this with the Hauppauge 955Q (2040:b123). dmesg shows the attached backtrace, using the same "arecord" command.
Looking at the code, it seems that cx231xx_usb_disconnect() holds a mutex while waiting for open fds to be closed [through cx231xx_close_extension() -> snd_card_free()], but snd_cx231xx_pcm_close() also grabs that mutex when closing the file on behalf of arecord.
This is obviously not desirable, but I don't know the correct way to fix it.
|