Date: Wed, 25 May 2022 21:26:45 +0000 From: bugzilla-noreply@freebsd.org To: gnome@FreeBSD.org Subject: [Bug 194727] uaudio device gets disconnected, and hangs usb until everything using /dev/mixer* is closed Message-ID: <bug-194727-6497-hy6PBISOm0@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-194727-6497@https.bugs.freebsd.org/bugzilla/> References: <bug-194727-6497@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194727 --- Comment #76 from Hans Petter Selasky <hselasky@FreeBSD.org> --- (In reply to Hans Petter Selasky from comment #71) > My complaint, and I think others have expressed this, is that a misbehavi= ng=20 > application should not prevent me from using the USB port the sound card = was=20 > inserted previously. A misbehaving application should not have the level = of=20 > control of the system. While PulseAudio is having an issue, the handling = of=20 > this situation needs to be more robust. Hi, The only responsibility of the kernel is to garbage collect memory and resources which are not freed when a user-space application exits. For example if you open a shared FIFO and don't read the data which is writ= ten there, the writer will eventually be blocked as the internal buffer it has = is used up! The same with USB. If you get any handle on a USB device, and don't free it when the device vanishes, the kernel will wait enumerating further devices, because it not only wants the memory back it also wants to free up unit num= bers for coming character device nodes. I'm not willing to leak memory as a compromise for faulty applications. But= I could be willing to implement a kill after timeout sysctl, that if an application using USB resources does not free up its handles and such, it g= ets automagically killed, like out of memory, OOM. What do you think about that? Applications and the kernel are in a symbiosis and must "talk" to each other correctly for things to work in the end. It's like a protocol. Audio applications may need realtime priority for example, to process audio= in time, but if they are broken, they may go looping and use 100% CPU and lock your system anyway. Again, if your application leaks file descriptors, and you think it is a bu= g, I would fix the application and not the kernel. --HPS --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-194727-6497-hy6PBISOm0>