On Thu, 04 Aug 2016 14:12:09 +0200, Takashi Sakamoto wrote: > > On Aug 4 2016 19:28, Mark Brown wrote: > > On Thu, Aug 04, 2016 at 12:17:57PM +0900, Takashi Sakamoto wrote: > >> On Jul 30 2016 07:08, Mark Brown wrote: > > > >>> The card should be deinstantiated and reinstantiated whenever a > >>> component driver unbinds and rebinds (respectively). You'd need to > >>> completely deregister the card to change the list of things it's > >>> expecting currently. > > > >> In a point of application interfaces, I guess that current implementation of > >> ALSA soc part includes a bug that it's possible to unload codec or component > >> modules when any ALSA character devices are opened. The framework has no > >> codes to manage reference counting of character devices or loaded codecs, > >> components. > > > > Yes, exactly - we don't cope very well with that situation and we really > > ought to but since it's hard to trigger without trying in practice it's > > never been a priority. > > Ugly... completely ugly idea for user space applications and operating > system... It's better for developers for ALSA soc part to pay enough > attention not only to their hardwares but also to application interfaces. > > Please assume that a loaded module for SoC's sound interface which > supports Jack detection, and pulseaudio runs on the system. Then, > typically, the process listen to ALSA ctrl character device for Jack > detection. > > In this case, when modules for codec or component are unloaded, what > happends? You can't unload. The module unload is already protected by the proper module refcounting. > In worst case, pulseaudio process can kill the system in a > system call path or something else, because the modules for SoC's sound > interface is still loaded and userspace applications can execute system > calls via ALSA character devices. > > It should be forbidden to build ALSA soc part as loadable kernel > modules. It's really danger... The only danger is about the dynamic unbinding, and it has nothing to do with the module. And, protecting the sysfs unbind itself is trivial, too: as I already suggested, we can put the flags in appropriate places. Takashi
