[alsa-devel] [PATCH] ASoC: dapm: Fix race condition in widgets power list creation

Peter Ujfalusi peter.ujfalusi at nokia.com
Tue Jan 18 13:34:13 CET 2011

On Tuesday 18 January 2011 14:08:51 ext Peter Ujfalusi wrote:
> Resend, since alsa-devel address was mistyped ;)
> On 01/18/11 13:39, ext Mark Brown wrote:
> > > I *suspect* that we're in a similar case and either the locking has
> > > been broken by the multi-component stuff or there's other cases that
> > > need protection, probably the jack detection code.
> The snd_soc_dapm_sync is just a wrapper for dapm_power_widgets, right?
> It (snd_soc_dapm_sync) is used in soc-core:soc_post_component_init.
> But there is no need for it, since the snd_soc_dapm_new_widgets will
> call dapm_power_widgets at the end. so we can remove the
> snd_soc_dapm_sync from there.
> For the rest:
> I would replace the snd_soc_dapm_sync calls in soc-dapm.c with
> dapm_power_widgets(dapm, SND_SOC_DAPM_STREAM_NOP); calls.
> Modify the snd_soc_dapm_sync to use the codec->mutex around the
> dapm_power_widgets call.
> In that way I think all race conditions going to be covered without
> adding new mutex.
> What do you think?
> I can make a patch...

Or not.. soc-jack.c:snd_soc_jack_report also calls snd_soc_dapm_sync, while 
keeping the codec->mutex locked...
Should machine drivers also take the mutex when they call snd_soc_dapm_sync?


More information about the Alsa-devel mailing list