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

[Liam Girdwood <lrg@slimlogic.co.uk>]

On Fri, 2010-11-05 at 10:38 -0400, Mark Brown wrote:
> 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.
> 

I think we need to consider non CODEC components too that have DAPM
controls (and have no CODEC mutex). i.e OMAP4 ABE. 

I'll try and look into this later as part of the OMAP4 upstream. Ideally
a card/DAPM mutex may be more desirable here.

Liam
-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk