Re: [PATCH] ASoC: core: Fix race in dapm_power_widgets

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Fri, Nov 05, 2010 at 09:53:35AM +0200, Peter Ujfalusi wrote:

> Well, I think if we want to have one place to use a lock, this is the highest we 
> can go.

This assumes that we've figured out the correct thing to lock and where
we need to hold it - if you want to lock the DAPM algorithm then that's
one thing, but it's not clear to me that this is the only thing we need
to lock or if we need to ensure that the users of DAPM are handled and
therefore this level of stuff becomes redundant.

> All other places, when dapm_power_widgets called are protected by codec->mutex 
> so those paths are safe.
> By replacing the custom kcontrol/callbacks with SOC_DAPM_PIN_SWITCH() the 
> problem is gone.
> So it seams that my case can be solved easily with the SOC_DAPM_PIN_SWITCH(), 
> but the race remains, and other setups might fail under some rare scenario

This is all smelling like we should be doing something to ensure that
all the controls take the CODEC lock.  We're relying pretty heavily on
that throughout the code so there's going to be other smoking guns
there.

> It might be a good idea to go through the machine drivers, and check for 
> snd_soc_dapm_sync usage.

I think so; probably any DAPM function has this issue.