Re: [ntdev] IRQL is property of a thread or processor

MBond · June 28, 2015, 7:47pm

It is a matter of debate, but IMHO it is more a property of the thread than the CPU - even though there are more levels where a thread cannot be rescheduled and may by hijacked than levels that are obviously per thread.

Ordinarily a thread itself decides what IRQL it wishes to run at - by calling various functions that raise IRQL from passive. In addition to a thread’s choice, the interrupt mechanism in the OS can execute code in arbitrary thread context. When this happens, the IRQL is assigned by the OS to the appropriate level when 'hijacking’ a thread to execute these routines

Again, it depends on your point of view, but Max’s answer of 'both’ it correct in every case

Sent from Surface Pro

From: Maxim S. Shatskih
Sent: ‎Sunday‎, ‎June‎ ‎28‎, ‎2015 ‎6‎:‎35‎ ‎PM
To: Windows System Software Devs Interest List

I have basic doubt as to IRQL is a property of a thread or Processor.

Both.

Mostly it is a property of the CPU, but the thread also remembers whether it is at APC or PASSIVE level.

and who decides which thread will be running at what IRQL,if its a property of thread.

The KeRaiseIrql/KeAcquireSpinLock calls decide this.

If its a property of processor then who raises and lowers the IRQL of a processor?

KeRaiseIrql does.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

MBond · June 29, 2015, 6:41pm

Peter, again it depends on how you look at it, but this statement is just silly

Of course threads have the concept of IRQL. The very notion that call sequence implies IRQL and the various entry points and DDIs are documented that way implicitly relies on that fact. How else could you read a function that handles a call back documented to run at passive and acquires a spin lock and say with any certainty at what IRQL the statements will execute. It is also true that all threads not currently running need not maintain this state because they must necessarily have been preempted by the schedule or entered a scheduler wait. And equally true that regardless of the IRQL that the thread maintains for itself, it may be hijacked to execute something else at a higher level. This hijacking is of course a per CPU thing as the whole notion of hijacking implies that for efficiency, don’t bother with a context switch but just use whatever thread happened to be running - this is called arbitrary thread context in MSDN

And when us 'experts’ disagree, how can one blame the OP for his confusion? Anton is quite right that this topic is confusing, although I disagree with his assessment that the OS should have implemented two different mechanisms for this.

Anyways I digress, but I have seen too much evil caused by poor programmers who assumed things like 'this cannot be a race condition because I have high IRQL and I own the CPU’

Sent from Surface Pro

From: xxxxx@osr.com
Sent: ‎Monday‎, ‎June‎ ‎29‎, ‎2015 ‎9‎:‎15‎ ‎AM
To: Windows System Software Devs Interest List

Ah! To the original question:

It is quite literally a property of the processor. The IRQL is a field in the PRCB and is maintained on a per-processor basis.

A thread may change the IRQL of the Processor, but it is not the only potential manager of the processor’s IRQL. Futher, the thread itself does not have the concept of IRQL. A thread only has a concept of IRQL as a side-effect of it being run on a processor, and when it is not running on a processor, it no longer has an IRQL.

Consider that the IRQL of the processor may be changed by the OS for numerous reasons unrelated to the thread that coincidentally happens to be running on the processor (and which is now subject to all the rules of the IRQL change). This happens, for example, when an interrupt is processed.

OK?

NOW… The only thing that makes this concept SLIGHTLY messy is IRQL APC_LEVEL, which messes with individual thread state. But that’s largely a detail to be ignored in the overall architectural discussion.

Peter
OSR
@OSRDrivers