Using StorPortInterlocked at DIRQL

Hi,

I want to use StorPortInterlocked functions to queue incoming requests and then process them in a DPC later. However I noticed that all StorPortInterlocked functions have the requirement of IRQL<= DISPATCH_LEVEL!
Since the Interrupt Lock is held at the place where I wish to queue the request, the IRQL will be DIRQL, and that rules out using these DDIs :frowning:

Is there any solution to this problem?

Btw I went ahead and used StorPortInterlockedPushEntrySList with Interrupt Lock held and it worked. I am not really looking forward to use it in my release code, but curious to know what kind of side effects are expected if I still use it at DIRQL?

Regards,
Suresh

Enable Verifier on your driver when testing, then you will see whether it *worked* or not.

Hmm, thanks, will do that.
But I am wondering if ExInterlockedPushEntryList is allowed at any IRQL then why StorPortInterlockedPushEntrySList is not?

Btw any hints for making the queuing work at DIRQL are welcome :slight_smile: Thanks in advance.

Regards,
Suresh

If the resource (a queue) is used within the Isr than any access to this resource must be synchronized with the Isr and that is what the interrupt lock is used for: synchronizing driver code with the Isr.

You don’t want to compete for the acquisition of another spin lock while you are holding the interrupt lock. So you have to go with the interrupt lock.

If you follow the documentation on this your Isr will stop interrupts, store whatever state/data it needs, and queue a DPC to run at dispatch level. There you can do the work you need, and re-enable interrupts.

Thats the classic way to do things.

You also need to use verifier at all times when developing your driver, it will catch potential page faults even if they don’t actually fault.

As a follow-up query, is it okay to use StorPortInterlockedPushEntrySList in dump mode where I am at HIGH_IRQL?

I understand that it is documented to be used at <= DISPATCH_LEVEL, but I guess there are no ‘side effects’ of using it at HIGH_IRQL because you are basically running it in a single threaded mode.

As a follow-up question, is it okay to use StorPortInterlockedPushEntrySList in dump mode that runs at HIGH_IRQL?

I understand that it is documented to be used at <= DISPATCH_LEVEL, but I guess there would be no ‘side effects’ when used at HIGH_IRQL because you are basically running in a single threaded mode.

This is very poor engineering.

Along with each API, you get a contract. That contract states the conditions under which the developer of the API will support using the API.

Your part of the contract is to only use the API under the circumstances that the contract states. That does NOT not include guessing at how the API is implemented and trying to therefore surmise when it might be OK to call the API outside of the circumstances stated in the documented contract.

Especially for something like maintaining an SLIST. Why would you even, for one minute, consider doing this? You want an SLIST that works at HIGH_LEVEL, write the code yourself. It’s not that hard, and will probably take you less time that it took for you to consider using the function outside of the way its documented and posting your question here.

I’m sorry if that seems like a harsh assessment… but that’s the essence of what I’d say to an engineer on my team here at OSR if they came to me with this same question.

Peter
OSR
@OSRDrivers

Thanks Peter, appreciate your response.
Basically I am using interlocked functions at many places in the IO path in normal mode and was being lazy for having to check for dump mode at each of those places and use an alternative.
But I get your point.
Probably it is better to change all StorPortInterlockedxxx with MyStorPortInterlockedxxx and then check for dump mode inside MyStorPortInterlockedxxx.