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

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

Thread specific IRQL's and processor specific IRQL's

OSR_Community_UserOSR_Community_User Member Posts: 110,217
1. where thread saves the information of IRQL, that thread is running?
2. where processor saves the information of IRQL, that processor is running at?
3. why paged memory can not be accessed at DPC Level?
4. why at DPC level, we can't wait infinitely?
5. how IRQL's of thread and processor are tracked?

Comments

  • wdwd Member - All Emails Posts: 26
    6. Beam directly into my brain so that I don't have to read anything...

    https://docs.microsoft.com/en-us/sysinternals/learn/windows-internals

    ...Would be a good place to start

    -Wade



    On Thu, Jul 5, 2018 at 5:32 AM, xxxxx@gmail.com <
    xxxxx@lists.osr.com> wrote:

    > 1. where thread saves the information of IRQL, that thread is running?
    > 2. where processor saves the information of IRQL, that processor is
    > running at?
    > 3. why paged memory can not be accessed at DPC Level?
    > 4. why at DPC level, we can't wait infinitely?
    > 5. how IRQL's of thread and processor are tracked?
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >



    --
    *Wade Dawson*
    *DT Multimedia*
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,914
    xxxxx@gmail.com wrote:
    > 1. where thread saves the information of IRQL, that thread is running?

    Why do you care?  Each processor has a processor context structure that
    holds current state information.  The IRQL is part of that.  Notice that
    the system interrupt controller also has to be programmed for the IRQL. 
    That's the point, after all -- insuring that the processor cannot be
    interrupted by a lower-IRQL source.


    > 2. where processor saves the information of IRQL, that processor is running at?

    Isn't that the same as question 1?


    > 3. why paged memory can not be accessed at DPC Level?

    Because the page manager also runs at dispatch.  When you run at
    dispatch level, you're doing so because you have some critical data
    structures that you need to protect, where system integrity would be
    compromised if these data structures were accessed.  You don't want to
    leave the system in that state while it goes to load and manage pages.


    > 4. why at DPC level, we can't wait infinitely?

    Again, you're running at dispatch level because you have data structures
    in an inconsistent state.  You don't want to leave things inconsistent
    for very long.  If you aren't manipulating critical data structures,
    then you don't need to be running at dispatch.  Also, often you're at
    dispatch because you grabbed some spin lock.  The longer you spend
    holding a spin lock, the higher the chances of a deadlock occurring.

    It's just good practice.  You only stay in a privileged state as long as
    you really need the privileges.


    > 5. how IRQL's of thread and processor are tracked?

    It's part of processor state, like the register set.  Just before it
    loads the new registers, which will start the thread running, it sets
    the current IRQL value and programs the interrupt controller.  When the
    thread switches back to kernel mode, the current IRQL value is saved
    just like the running register set.

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • anton_bassovanton_bassov Member Posts: 4,928
    <quote>

    > 3. why paged memory can not be accessed at DPC Level?

    Because the page manager also runs at dispatch.? When you run at dispatch level, you're doing so because you have some critical data structures that you need to protect, where system integrity would be compromised if these data structures were accessed.? You don't want to leave the system in that state while it goes to load and manage pages.

    </quote>


    Sorry,Tim, but you are wrong here......

    It has nothing to do with some mythical "page manager" that supposedly runs at DPC level
    (in fact, this mythical "page manager's" job involves multiple dedicated MM threads and complex interactions between MM, Cache Manager and FSD)

    The only reason why you cannot access paged memory at elevated IRQL is because a hard page fault cannot get resolved without putting the failing thread to sleep, which cannot be done at elevated IRQL More on it below.......



    <quote>


    > 4. why at DPC level, we can't wait infinitely?

    Again, you're running at dispatch level because you have data structures in an inconsistent state.? You don't want to leave things inconsistent for very long.? If you aren't manipulating critical data structures, then you don't need to be running at dispatch.? Also, often you're at dispatch because you grabbed some spin lock.? The longer you spend holding a spin lock, the higher the chances of a deadlock occurring. It's just good practice.? You only stay in a privileged state as long as you really need the privileges.



    </quote>


    OMG....

    What's wrong with you today??? You are giving wrong answers all over the place


    Basically, this is just a convention - by elevating IRQL > APC_LEVEL you indicate that you want to disable context switches on a given CPU at the moment. The reason why you may want to disable context switches is that you may be either running in atomic context (i.e. ISR or DPC that does not have its own stack and hijacks the one of any thread that happens to be running at the time of interrupt), or running in a thread context but synchronising with the atomic one ( i.e holding a spinlock) at the moment.



    Your answer concerning the consistency is simply wrong. If it was only all about preserving the consistency per se, then a dispatcher-level construct like event or mutex (i.e. the one that allows blocking) would suffice here. However, you cannot go blocking (and, hence,cannot use these constructs) in atomic context, because you have no stack of your own and have to hijack the one of some other thread. The only synch option that is available to you at this point is a spinlock.


    No matter how long you are holding a spinlock, the very fact of holding the one for a long time does not lead to a deadlock, contrary to your claim. The deadlock will occur only if the same CPU tries to acquire a spinlock recursively. At this point the CPU will deadlock without any chance of ever resolving the situation, and all other CPUs will eventually follow the same path when they try to acquire the spinlock in question. This is why a spinlock holder that is running in thread context
    has to disable context switches on a given CPU - it has to make sure that the same CPU does not try to acquire the same spinlock in context of another thread.

    Contrary to your claim, this is not a "just a good practice" but a crucial and essential step that has to get taken in order to ensure that the system operates properly..


    Anton Bassov
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
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space