On Thu, Nov 04, 2010 at 04:18:03PM +0200, Peter Ujfalusi wrote:
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.
Sure, it's fairly clear how this could fall over.
I did not find lower level point where I can safely deal with this problem.
Right, that's what I was thinking - I'm mostly concerned that we need to have the locking further up the stack rather than further down. This feels like a band aid which fixes the symptom (the list pointers getting corrupted) but it smells like we may have something further up the stack which can still create issues. For example, if both DAPM and something else manipulate the register map simultaneously we could get R/M/W issues.