I found myself needing to protect some shared resources during
interrupt handling in a STORport miniport driver. No big deal right?
Just use the provided API call, StorPortSynchronizeAccess.
Here is what I experience.
When I call StorPortSynchronizeAccess from the ISR I get a deadlock.
The doc for StorPortSynchronizeAccess states that it takes the
interrupt spin lock to block new interrupts until the synchronization
function has finished.
BUT
The doc for HwStorInterrupt states that the interrupt spin lock is
taken BEFORE STORport calls HwStorInterrupt.
So if the interrupt spin lock is already taken and it tries to take it
again! DEADLOCK! The debugger appears to show the deadlock. The
first call to StorPortSynchronizeAccess is waiting on an interrupt
spin lock that is being held…
So using the ?provided? method to synchronize access to shared
resources DOES NOT WORK??
I hope I am making a mistake here.
Please correct my stupid programmer trick.
TIA,
Robert.
–
Robert Randall | xxxxx@gmail.com
You already have the interrupt spinlock in your isr. You call
StorPortSynchronizeAccess ONLY FROM OUTSIDE your isr context to sync
with your isr.
Mark Roddy
On Thu, Mar 31, 2011 at 11:15 AM, Robert Randall
wrote:
> I found myself needing to protect some shared resources during
> interrupt handling in a STORport miniport driver. ?No big deal right?
> Just use the provided API call, StorPortSynchronizeAccess.
>
> Here is what I experience.
>
> When I call StorPortSynchronizeAccess from the ISR I get a deadlock.
>
> The doc for StorPortSynchronizeAccess states that it takes the
> interrupt spin lock to block new interrupts until the synchronization
> function has finished.
>
> BUT
>
> The doc for HwStorInterrupt states that the interrupt spin lock is
> taken BEFORE STORport calls HwStorInterrupt.
>
>
> So if the interrupt spin lock is already taken and it tries to take it
> again! ?DEADLOCK! ?The debugger appears to show the deadlock. ?The
> first call to StorPortSynchronizeAccess is waiting on an interrupt
> spin lock that is being held…
>
> So using the ?provided? method to synchronize access to shared
> resources DOES NOT WORK??
>
> I hope I am making a mistake here.
>
> Please correct my stupid programmer trick.
>
> TIA,
> Robert.
>
> –
> Robert Randall | xxxxx@gmail.com
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
Robert Randall wrote:
I found myself needing to protect some shared resources during
interrupt handling in a STORport miniport driver. No big deal right?
Just use the provided API call, StorPortSynchronizeAccess.
Here is what I experience.
When I call StorPortSynchronizeAccess from the ISR I get a deadlock.
Of course you do. Don’t do that.
The doc for StorPortSynchronizeAccess states that it takes the
interrupt spin lock to block new interrupts until the synchronization
function has finished.
BUT
The doc for HwStorInterrupt states that the interrupt spin lock is
taken BEFORE STORport calls HwStorInterrupt.
So if the interrupt spin lock is already taken and it tries to take it
again! DEADLOCK! The debugger appears to show the deadlock. The
first call to StorPortSynchronizeAccess is waiting on an interrupt
spin lock that is being held…
So using the ‘provided’ method to synchronize access to shared
resources DOES NOT WORK??
Not at all. You are simply misusing the method. What
StorPortSynchronizeAccess does (essentially) is to raise the IRQL of the
function so that the interrupt handler cannot run while the callback
finishes. That isn’t NECESSARY in the interrupt handler, because you
are ALREADY at a raised IRQL.
The answer is that you do not NEED to call StorPortSynchronizeAccess in
the interrupt handler. It already has the protection that SPSA grants
to other functions. It is already safe.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Robert,
I am assuming that you need to protect access to resources between ISR on one processor and StartIo thread on another processor.
If so, you need to use StorPortSynchronizeAccess in the StartIo context. This will ensure that only one of the ISR or StartIo will
execute on any processor.
Regards,
Girish.
As usual, context is everything!
I feel I understand but it raises another question:
What is the difference between using
StorPortSynchronizeAccess
and taking the interrupt spin lock directly using
StorPortAcquireSpinLock
TIA,
Robert.
On Thu, Mar 31, 2011 at 11:36 AM, Girish Aithal wrote:
> Robert,
> ? I am assuming that you need to protect access to resources between ISR on
> one processor and StartIo thread on another processor. If so, you need to
> use StorPortSynchronizeAccess in the StartIo context. This will ensure that
> only one of the ISR or StartIo will execute on any processor.
>
> Regards,
> Girish.
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Robert Randall | xxxxx@gmail.com
Mostly it is programming style. The StorPortAcquireSpinLock interface
allows you to acquire/release the lock within a function while
StorPortSynchronizeAccess calls the indicated function with the lock
held. The nice chart in the docs for StorPortAcquireSpinLock indicate
which standard miniport routines hold which locks - and the required
lock acquisition order.
Mark Roddy
On Thu, Mar 31, 2011 at 12:58 PM, Robert Randall
wrote:
> As usual, context is everything!
>
> I feel I understand but it raises another question:
>
> What is the difference between using
> StorPortSynchronizeAccess
> and taking the interrupt spin lock directly using
> StorPortAcquireSpinLock
>
> TIA,
> Robert.
>
> On Thu, Mar 31, 2011 at 11:36 AM, Girish Aithal wrote:
>> Robert,
>> ? I am assuming that you need to protect access to resources between ISR on
>> one processor and StartIo thread on another processor. If so, you need to
>> use StorPortSynchronizeAccess in the StartIo context. This will ensure that
>> only one of the ISR or StartIo will execute on any processor.
>>
>> Regards,
>> Girish.
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> –
> Robert Randall | xxxxx@gmail.com
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>When I call StorPortSynchronizeAccess from the ISR I get a deadlock.
Do not do this.
Call it only in non-ISR code which will need to synchronize with the ISR.
This function just takes an interrupt spinlock, and the ISR is called by the kernel with this lock already held.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com