Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Using StorPortInterlocked at DIRQL

Suresh_PatilSuresh_Patil Member Posts: 122
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 :(

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

Comments

  • matt_sykesmatt_sykes Member - All Emails Posts: 270
    Enable Verifier on your driver when testing, then you will see whether it *worked* or not.
  • Suresh_PatilSuresh_Patil Member Posts: 122
    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 :-) Thanks in advance.

    Regards,
    Suresh
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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.
  • matt_sykesmatt_sykes Member - All Emails Posts: 270
    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.
  • Suresh_PatilSuresh_Patil Member Posts: 122
    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.
  • Suresh_PatilSuresh_Patil Member Posts: 122
    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.
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,685
    <quote>
    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
    </quote>

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Suresh_PatilSuresh_Patil Member Posts: 122
    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.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 20 Apr 2020 LIVE ONLINE
Writing WDF Drivers 11 May 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA