[PATCH 1/6] strmbase: Fix race condition on InputPin_BeginFlush between csRenderLock and filter.csFilter.

[Erich E. Hoover]

Finally took the time to track down bug #31566 (Fallout 3/NV radio
problems) after the big move to strmbase.  This patch changes the
locking order between csRenderLock and filter.csFilter to keep a race
condition from occurring when BaseRendererImpl_Receive and
BaseRenderer_InputPin_BeginFlush are called.

After carefully combing the strmbase code it is pretty clear that
csRenderLock is the "bigger" lock (when compared to filter.csFilter),
but the case described above triggers the particular instantiation of
the problem in F3/FNV:
== Thread 1==
BaseRendererImpl_Receive
 -> EnterCriticalSection(csRenderLock);
 -> ...
 -> QualityControlRender_BeginRender
     -> ReferenceClock_GetTime
         -> EnterCriticalSection(filter.csFilter);
         -> ...
         -> LeaveCriticalSection(filter.csFilter);
 -> ...
 -> LeaveCriticalSection(csRenderLock);
== Thread 2==
BaseRenderer_InputPin_BeginFlush
 -> EnterCriticalSection(filter.csFilter);
 -> EnterCriticalSection(csRenderLock);
 -> ...
 -> LeaveCriticalSection(filter.csFilter);
 -> LeaveCriticalSection(csRenderLock);

As you can see, the lock order here means that if
BaseRenderer_InputPin_BeginFlush occurs while
BaseRendererImpl_Receive is being processed that it will lock the
"inner" lock (filter.csFilter) and then both locks will be set,
causing a deadlock.  Patches 2-5 standardize the rest of the locking
in strmbase/quartz to match this behavior (where it doesn't already).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-strmbase-Fix-race-condition-on-InputPin_BeginFlush-b.patch
Type: text/x-diff
Size: 934 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20140730/b1e2e486/attachment.patch>