why we can access memory from non paged pool at or above DISPATCH LEVEL

Question

As I know that if IRQL level is dispatch then you can access memory from non paged pool. if we will try to access memory from paged pool.just wanted to know why ?

Answer 1

"why we can access memory from non paged pool at or above DISPATCH LEVEL" is a statement, question is why we cannot access memory from paged pool IRQL >= DISPATCH_LEVEL?

Well...

"Any routine that is running at greater than IRQL APC_LEVEL can neither allocate memory from paged pool nor access memory in paged pool safely. If a routine running at IRQL greater than APC_LEVEL causes a page fault, it is a fatal error."

-- http://msdn.microsoft.com/en-us/library/windows/hardware/ff554368(v=vs.85).aspx

Why is this:

suppose your driver is servicing an interrupt, and while at it, it holds a spin lock. Now, you want to access some data structure that resides on the paged pool and as you are already out of luck, that data is on a page that has been paged-out by the memory manager.

Now, your driver has to wait until the memory manager page-in your data. You are blocking/waiting/sleeping, actually your driver is.

Now, another interrupt occurs, but since you are still waiting for the data to be paged-in, what do you think what will happen now?

Know this,

" Holding a spin lock for an unnecessarily long duration can hurt system-wide performance."

as your driver waits longer for something to happen, your kernel will go to freeze.

Also,

"Note that a thread may not block while holding a spinlock, because that could cause deadlock. Further, preemption is disabled on a given processor while a spinlock is held."

-- https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/synchronization/synchronization.html

anyway, read this further:

"Driver code that runs at IRQL > PASSIVE_LEVEL should execute as quickly as possible. The higher the IRQL at which a routine runs, the more important it is for good overall performance to tune that routine to execute as quickly as possible. For example, any driver that calls KeRaiseIrql should make the reciprocal call to KeLowerIrql as soon as it can."

-- http://msdn.microsoft.com/en-us/library/windows/hardware/ff554368(v=vs.85).aspx

Page fault is an exception that needs to be serviced quickly by the memory manager. While your driver holds spinlock and holds that processor hostage, that processor is as good as dead right now.

MSDN says:

"While a driver routine holds a spin lock, it cannot cause a hardware exception or raise a software exception without bringing down the system. In other words, a driver's ISR and any SynchCritSection routine that the driver supplies in a call to KeSynchronizeExecution must not cause a fault or trap, such as a page fault or an arithmetic exception, and cannot raise a software exception. A routine that calls KeAcquireSpinLock or KeAcquireInStackQueuedSpinLock also cannot cause a hardware exception or raise a software exception until it has released its executive spin lock and is no longer running at IRQL = DISPATCH_LEVEL."

-- http://msdn.microsoft.com/en-us/library/windows/hardware/ff559854(v=vs.85).aspx

All this answers what will happen, or what can happen. As to answer Why we cannot use paged memory above or at DISPATCH_LEVEL:

1. It leads to deadlock most of the time, which in kernel world is kernel-crash.
2. It will induce latency in kernel, which is bad.
3. Refer to 1, that's kind of important.

I have tried to fetch as much relevant information as possible, if you are still not sold, try reading on spin-locks, re-entrant functions, interrupt handling, Paging. Try reading for Linux, Windows, and Apple's OS's kernel. They all say same things with varying details.