Receive() indications and IRQL

Home Forums Discussions General Discussion Receive() indications and IRQL

This topic contains 4 replies, has 2 voices, and was last updated by  s0larian 11 years, 3 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #5049

    s0larian
    Participant

    Hi there,

    I have just spent a some time debugging an issue, and I was was wondering, if someone has seen something similar.

    The test case:

    • I have a kernel mode thread that, naturally, runs at PASSIVE_LEVEL
    • every now and then the thread wakes up and submits a packet using the ReceiveHandler function from the original NDIS_OPEN_BLOCK

    The issue:

    • sometimes IRQL remains at DISPATCH_LEVEL after the ReceiveHandler has returned

    In any case, I have managed to work around the problem by explicitly lowering the IRQL to PASSIVE_LEVEL, but, this really looks like a bug somewhere… Almost like a piece of MS code assumes that the handler should run at DISPATCH_LEVEL… Or may be they forget to unlock a spinlock…

    Other observations:

    • I think this happens when tcpip.sys handles a TCP+SYN, and a Send function is invoked directly with a SYN/ACK… but I am not completely certain.
    • This particular problem is detected by the driver verifier when submitting a packet from a DeviceIOControl handler, since IRQL is different on the way out of the handler.
    • Another similar thing happens when my thread calls KeWaitForSingleObject() and the verifier bitches about IRQL being too high.

    Any ideas or suggestions?
    Thanks in advance!

    #6121

    Vadim Smirnov
    Moderator

    Protocol driver expects that its ProtocolReceive handler is called at DISPATCH_LEVEL (refer the DDK documentation where it is explicitely specified “…ProtocolReceive runs at IRQL = DISPATCH_LEVEL…”).

    Since protocol driver assumes that it was called at DISPATCH_LEVEL then it could use KeAcquireSpinLock/KeReleaseSpinLockFromDpcLevel, an example instead KeAcquireSpinLock/KeReleaseSpinLock or something similar. It is not a good sample but when called on DISPATCH_LEVEL both pairs work on the same way.

    #6122

    s0larian
    Participant

    Oh, I think I get it…. I was tracing KeAcquireSpinLock() yesterday, and it only incremented the IRQL. That’s all that’s required on uniprocessor kernels, actually.

    So, in this case, I wonder if it’s a good idea to raise IRQL to dispatch prior invoking Receive() handlers?

    Thanks!

    #6123

    Vadim Smirnov
    Moderator

    So, in this case, I wonder if it’s a good idea to raise IRQL to dispatch prior invoking Receive() handlers?

    Yes, this is basically what you have to do.

    #6124

    s0larian
    Participant

    Thank you, I appreciate your help.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.