On Thursday 04 November 2010 15:43:54 ext Mark Brown wrote:
On Thu, Nov 04, 2010 at 10:16:45AM +0200, Peter Ujfalusi wrote:
The exisiting card->mutex can not be used for this purpose, since it has been taken in probe time in the snd_soc_instantiate_card function. Through probe calls from this function eventually dapm_power_widgets will be called, which will lead to dead lock.
Hrm. You're right that the card mutex has issues here but just adding a lock here leaves us with a race - whenever we make a change to widget power we're doing a read/modify/write cycle and those aren't locked at all. I'm not sure if we need a lower level lock to fix that, or a higher level lock which would make this one redundant but we ought to think about it and make sure we've picked the right way.
It is really hard to see what is actually happening, but based on my observation the root is this: the widget's power_list going to be modified during the dapm_power_widgets call. If the previous call to dapm_power_widgets did not finished, and it is going through the widget's power_list, another call to dapm_power_widgets might cause the power_list to be changed. This leads to a crash. It is possible that the list which existed in the first dapm_power_widgets call got distroyed by the second call while the first instance was going through that. IMHO in most cases the new mutex is not going to add much delay, since it is really rare case, when we can hit this bug.
I did not find lower level point where I can safely deal with this problem.