Thread specific IRQL's and processor specific IRQL's

  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?
  1. 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: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>


Wade Dawson
DT Multimedia</http:></http:>

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.

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

Isn’t that the same as question 1?

  1. 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.

  1. 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.

  1. 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.

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…

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