[alsa-devel] Is add uevent of controlC still a reliable synchronization point?

[Takashi Iwai]

On Wed, 16 May 2018 00:22:40 +0200,
Tzung-Bi Shih wrote:
> 
> We noticed the issue because in some rarely case the code will be executed
> by worker of workqueue (i.e. deferral probe since v3.4) instead of udevd.
> As a result, applications rely on the change uevent of sound card (fired
> from 78-sound-card.rules) will be signaled prematurely.  The applications
> assume when they receive the signal, everything of the sound card should be
> ready.  But in the case, they are still initializing.
> 
> We have tried to change the order of SNDRV_DEV_CONTROL to the last one to
> fix the bug we met and it was doing great.  So if there will not bring any
> side effect, it should be fine to apply the patch.

The register and disconnect should be OK, as they are merely the parts
to expose to and hide from user-space.

> By the way, out of curiosity, prior to the commit 289ca025ee1d, it seems
> the list is merely a FIFO.  How to ensure control device is the last one to
> register at that time?

It's just the fact that snd_ctl_new() is called inside the
snd_card_new(), i.e. it's the very first one to be added.

If the patch works for you, please give your tested-by tag, so that
I'll merge it to for-next branch.  It looks like a too intrusive
change for 4.17-rc6, so maybe safer to queue for 4.18.


thanks,

Takashi