Re: Question about struct snd_soc_dai() :: cpu_dai->codec

[Takashi Iwai <tiwai@suse.de>]

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