compiler intrinsic ExInterlockedRemoveEntryList

NTDEV
21

What amazes me is that a piece of crap code I wrote in 2002 is still being
discussed. The OP posited the question because he’s been tasked to make the
driver work on AMD64. Frankly what needs to be done is, as I said earlier,
scrap the current implementations of the bus and peer to peer drivers, and
write them using KMDF.

Oh well …

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Saturday, February 27, 2010 9:10 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] compiler intrinsic ExInterlockedRemoveEntryList

Huh?

I’m not sure I understand the question, so I’ll take it as face value and
answer that.

Because the operations aren’t equivalent. KeRaiseIrql does what the name
suggests… it raises the IRQL and nothing more. KeSynchronizeExecution
acquires the interrupt spin lock (which implies raising the IRQL to the
driver’s synchronize IRQL). Both useful operations, but not the same.

Consider that you could (COULD, I’m not recommending this, but it’s entirely
possible) build your own locking primitive using a the IRQL of your choice
and an interlocked bit test and set operation (or interlocked exchange or…
you pick one).

You’re asserting that KeRaiseIrql to IRQL HIGH_LEVEL is special cased in
Windows? Are you sure of this?

Peter
OSR

NTDEV is sponsored by OSR

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

__________ Information from ESET Smart Security, version of virus signature
database 4900 (20100227) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus signature
database 4900 (20100227) __________

The message was checked by ESET Smart Security.

http://www.eset.com

22

>Consider that you could (COULD, I’m not recommending this, but it’s >entirely possible) build your own locking primitive using a the IRQL of your >choice and an interlocked bit test and set operation (or interlocked >exchange or… you pick one).
I referenced to original post.
"The routine below needs to lock out interrupts as the list can be manipulated in both ISR and non-ISR context. It also needs to be multi-processor safe. "
And later another person answered

">code inside #elif AMD64 with _disable() and _enable().
Raise the IRQL to HIGL_LEVEL instead.
"
I want to understand in which cases it is possible to just rise IRQ to HIGL_LEVEL to synchronize non-ISR with ISR. And when is necessary to use KeSynchronizeExecution ?
I understand how KeSynchronizeExecution works and I always use this function to synchronize access to hardware register. Now I got information that would be another way for synchronization.
In general what would be the best answer for original question?

Igor Sharovar

23

Actually, if it is for recent OS’es only, I would use
KeAcquireInterruptSpinLock / KeReleaseInterruptSpinLock. No it is not
enough just to raise to HIGH_LEVEL since that only impacts one
processor. So you at a minimum need to create a spinlock like model
that raises to the level of the DIRQL you are trying to protect against,
and that is what interrupt spinlocks do.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@hotmail.com” wrote in message
news:xxxxx@ntdev:

> >Consider that you could (COULD, I’m not recommending this, but it’s >entirely possible) build your own locking primitive using a the IRQL of your >choice and an interlocked bit test and set operation (or interlocked >exchange or… you pick one).
>
> I referenced to original post.
> "The routine below needs to lock out interrupts as the list can be manipulated in both ISR and non-ISR context. It also needs to be multi-processor safe. "
> And later another person answered
>
> ">code inside #elif AMD64 with _disable() and _enable().
> Raise the IRQL to HIGL_LEVEL instead.
> "
> I want to understand in which cases it is possible to just rise IRQ to HIGL_LEVEL to synchronize non-ISR with ISR. And when is necessary to use KeSynchronizeExecution ?
> I understand how KeSynchronizeExecution works and I always use this function to synchronize access to hardware register. Now I got information that would be another way for synchronization.
> In general what would be the best answer for original question?
>
> Igor Sharovar

Information from ESET Smart Security, version of virus
signature database 4900 (20100227)

The message was checked by ESET Smart Security.

http://www.eset.com

24

Peter, when I listen to people who think KeRaiseIrql to DIRQL is the same as
KeSynchronizeExecution, it’s usually because those people think that
KeRaiseIrql affects all the processors in the system or it hasn’t occurred
to them yet that there can be more than one processor in your code at the
same time.

–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.

wrote in message news:xxxxx@ntdev…
>


>
> Huh?
>
>


>
> I’m not sure I understand the question, so I’ll take it as face value and
> answer that.
>
> Because the operations aren’t equivalent. KeRaiseIrql does what the name
> suggests… it raises the IRQL and nothing more. KeSynchronizeExecution
> acquires the interrupt spin lock (which implies raising the IRQL to the
> driver’s synchronize IRQL). Both useful operations, but not the same.
>
> Consider that you could (COULD, I’m not recommending this, but it’s
> entirely possible) build your own locking primitive using a the IRQL of
> your choice and an interlocked bit test and set operation (or interlocked
> exchange or… you pick one).
>
>


>
> You’re asserting that KeRaiseIrql to IRQL HIGH_LEVEL is special cased in
> Windows? Are you sure of this?
>
> Peter
> OSR
>
>

25

> I want to understand in which cases it is possible to just rise IRQ to HIGL_LEVEL to synchronize non-

ISR with ISR.

On UP only.

And when is necessary to use KeSynchronizeExecution ?

Always.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

26

“Don Burn” wrote in message news:xxxxx@ntdev…
>
> “Pavel A.” wrote in message news:xxxxx@ntdev:
>
>> KeRaiseIrql(HIGH_LEVEL) is just one quick “cli” instruction.
>
> When did this change occur? I know it was not the case for all versions
> of NT and for Windows 2000. Since then I have not walked that path, but
> AFAIK it is not a “CLI”.

Don,

I’m sorry I should be more accurate. The exported KeRaiseIrql (or
KfRaiseIrql)
does not compile to a single instruction, as it is not inline.

But I believe HIGH_LEVEL is equivalent to cli, at least on IA32.
IIRC quite long ago somebody from MS (Doron?) explained that old style
interlocked functions like ExInterlockedInsertHeadList acquire their
spinlock argument at HIGH_LEVEL, since they can be called from any irql.

Disassembling ExInterlockedInsertHeadList on WinXP (x86) shows:
pushfd
cli
…
popfd

Regards,
– pa

27

Right… but the fact that there’s a CLI is a detail of how the ExInterlocked list functions work. It’s not correct to take this clever implementation detail and jump to the conclusion that IRQL HIGH_LEVEL clears the processor’s interrupt enable flag.

Peter
OSR