[ofw] Opensm & WinMad: a race, cauing BSOD722

[Hefty, Sean]

> I've replaced mutex by spinlock - see below.
> I did it also for WinMad, albeit it has no asynchronous callbacks like
> WinVerbs.
> The main reason is to keep it similar to WinVerbs as it is today.
> A minor, mostly theoretical one: there are other functions, which are using
> today the provider mutex. It seems for me worthful to keep for them
> possibility to call a low-level WvProviderGet function.
> What's your opinion ?

As a theoretical preference, I prefer to use a guarded mutex wherever possible, specifically so we know that the objects being protected may not be accessible from DPC, which gives us a convenient stack dump.  My guess is that it's faster than a spinlock as well.  The other issue is that if we're trying to synchronize between a passive level thread and one at DPC, then the passive level thread can't acquire, then release a spinlock.  That puts the thread back at passive level, which the DPC thread could then starve.  Does any of this apply to this patch?  Probably not...

I think an easier fix for the crash is to simply call InterlockedIncrement() directly in the offending callback, rather than WvProviderGet().  This would clarify in the code that we must already be holding a reference on the provider and that destruction during that time is not something which needs to be handled.  I.e. a call to WvProviderGet() would always succeed.  But if you've already committed your change, I'm fine leaving it.