[alsa-devel] Question about struct snd_soc_dai() :: cpu_dai->codec

[Takashi Sakamoto]

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? 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...


Regards

Takashi Sakamoto

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20160804/4e7ee79b/attachment.sig>