分析驱动程序在IRQL>=DISPATCH_LEVEL时和DPC过程中不能用KeWaitForSingleObject等待对象的原因

    M$ddk对调用KeWaitForSingleObject接口有下面约定:

Callers of KeWaitForSingleObject must be running at IRQL <= DISPATCH_LEVEL.
 However, if Timeout = NULL or *Timeout != 0, the caller must be running at IRQL <= APC_LEVEL and in a nonarbitrary thread context. 
(If Timeout != NULL and *Timeout = 0, the caller must be running at IRQL <= DISPATCH_LEVEL.)

    翻译过来就是以Timeout!=0调用KeWaitForSingleObject时,IRQL<DISPATCH_LEVEL,如果要在IRQL=DISPATCH_LEVEL运行级上调用KeWaitForSingleObject,必须保证Timeout=0.这段话短短几行,但是有3个重要的信息点,1.等待的超时时间在不同irql上该怎么设置;2.dpc过程中不能执行超时时间为非零等待;3.当IRQL>=DISPATCH_LEVEL时,也不能执行非零等待。本文将结合自己对Reactos的理解,对这3点进行解释。


1.IRQL>=DISPATCH_LEVEL时,超时时间必须==0?

KeWaitForSingleObject是个等待-醒来-再等待的循环过程,每次醒来会判断条件是否满足,不满足就继续等待。其中有一项参数就是Timeout是否超时。

NTSTATUS
NTAPI
KeWaitForSingleObject(IN PVOID Object,
                      IN KWAIT_REASON WaitReason,
                      IN KPROCESSOR_MODE WaitMode,
                      IN BOOLEAN Alertable,
                      IN PLARGE_INTEGER Timeout OPTIONAL)
{

    for (;;)
    {
         if (Timeout)
            {
                /* Check if the timer expired */
                InterruptTime.QuadPart = KeQueryInterruptTime();
                if ((ULONGLONG)InterruptTime.QuadPart >=
                    Timer->DueTime.QuadPart)
                {
                    /* It did, so we don't need to wait */
                    WaitStatus = STATUS_TIMEOUT;
                    goto DontWait;
                }

                /* It didn't, so activate it */
                Timer->Header.Inserted = TRUE;
            }
            ...
            WaitStatus = KiSwapThread(Thread, KeGetCurrentPrcb());
 WaitStart:
        Thread->WaitIrql = KeRaiseIrqlToSynchLevel();
        KxSingleThreadWait();
        KiAcquireDispatcherLockAtDpcLevel();
    } //end for(;;)
    KiReleaseDispatcherLock(Thread->WaitIrql);
    return WaitStatus;

DontWait:
    KiReleaseDispatcherLockFromDpcLevel();
    KiAdjustQuantumThread(Thread);
    return WaitStatus;
}

代码显示,如果Timeout!=NULL,且只有已超时,就跳出for(;;)循环并从KeWaitForSingleObject函数中返回;否则,可能进入KiSwapThread(Thread, KeGetCurrentPrcb());进而切换线程,实现睡眠等待。 从上面这段代码摘要可以知道,调用KeWaitForSingleObject且Timeout!=NULL,会引起线程等待。为了使线程在DISPATCH_LEVEL上不被因睡眠而切换出去,只能让超时值==0,使得KeWaitForSingleObject立刻返回。这解释了ddk文档中关于Timeout的调用约定。

2.dpc过程中不能执行超时时间为非零等待?

    网上一种主流的说法是:线程运行在DISPATCH_LEVEL级别以下,在IRQL==DISPATCH_LEVEL时 线程被挂起,OS开始调度和切换线程,等到IRQL重新下降到DISPATCH_LEVEL以下时,被调度的线程才继续运行。如果此时线程睡眠,会因为没法切换回来而导致BDOS。但是,这个说法有点牵强,首先,下降到DISPATCH_LEVEL级别一下是个很模糊的时机,是在下降沿切换还是下降完毕才切换?其次,难道线程通过执行RaiseIrql就被挂起了?更重要的,这句话容易引起误解:认为winos跟linux一样,存在专司线程调度的内核线程,该线程只有在DISPATCH_LEVEL时才调度和切换线程。然而,winos中不存在固定的调度线程,取而代之的,线程调度遍地都是,只要调用LowIrql/KiExitDispatcher都会引起线程调度(这是分布式调度的调调吗?)。 另外,如果仔细看KiSwapThread/SwapContext的实现就可以知道,被切换的线程在SwapContext中就已经恢复执行,而,IRQL下降只是提供线程切换的机会。因此,分析LowIrql(以及其他会降低cpu当前irql的操作)源码就显得很重要。

来看下LowIrql的代码:

VOID
HalpLowerIrql(KIRQL NewIrql)
{
  if (NewIrql >= PROFILE_LEVEL)
    {
      KeGetPcr()->Irql = NewIrql;
      return;
    }
 ...
  if (NewIrql >= DISPATCH_LEVEL)
    {
      KeGetPcr()->Irql = NewIrql;
      return;
    }
  KeGetPcr()->Irql = DISPATCH_LEVEL;
  if (((PKIPCR)KeGetPcr())->HalReserved[HAL_DPC_REQUEST])
    {
      ((PKIPCR)KeGetPcr())->HalReserved[HAL_DPC_REQUEST] = FALSE;
      KiDispatchInterrupt();
    }
  KeGetPcr()->Irql = APC_LEVEL;
  if (NewIrql == APC_LEVEL)
    {
      return;
    }
  if (KeGetCurrentThread() != NULL && 
      KeGetCurrentThread()->ApcState.KernelApcPending)
    {
      KiDeliverApc(KernelMode, NULL, NULL);
    }
  KeGetPcr()->Irql = PASSIVE_LEVEL;
}
如前所述,当IRQL级别下降时,可能会引起线程切换,它会调用KiDispatchInterrupt()执行dpc过程和软中断请求:

.func KiDispatchInterrupt@0
_KiDispatchInterrupt@0:

    /* Deliver DPCs */
    mov ecx, [ebx+KPCR_PRCB]
    call @KiRetireDpcList@4

...

    /* Set APC_LEVEL and do the swap */
    mov cl, APC_LEVEL
    call @KiSwapContextInternal@0

    /* Restore registers */
    mov ebp, [esp+0]
    mov edi, [esp+4]
    mov esi, [esp+8]
    add esp, 3*4

Return:
    /* All done */
    ret

...
.endfunc
call KiRetireDpcList遍历Prcb->DpcData队列,出队并执行每个dpc过程。而call KiSwapContextInternal则完成线程切换的功能,具体的源码就不深入进去看了,可以参考毛德操的情景分析。值得一提的是,在KiSwapContextInternal里,实实在在的存在判断当前线程切换是不是在发生在dpc过程中:

.globl @KiSwapContextInternal@0
.func @KiSwapContextInternal@0, @KiSwapContextInternal@0
@KiSwapContextInternal@0:
...
    /* DPC shouldn't be active */
    cmp byte ptr [ebx+KPCR_PRCB_DPC_ROUTINE_ACTIVE], 0
    jnz BugCheckDpc
汇编中KPCR_PRCB_DPC_ROUTINE_ACTIVE是prcb中的域,对应 Prcb->DpcRoutineActive。这里判断该域是否为0,非零就跳去蓝屏。那这个域是什么时候设置的?

正好在KiRetireDpcList准备调用执行Dpc过程中:

FASTCALL
KiRetireDpcList(IN PKPRCB Prcb)
{
...
    DpcData = &Prcb->DpcData[DPC_NORMAL];
    ListHead = &DpcData->DpcListHead;

    /* Main outer loop */
    do
    {
        /* Set us as active */
        Prcb->DpcRoutineActive = TRUE;
        ...
        DeferredRoutine(Dpc,
                                DeferredContext,
                                SystemArgument1,
                                SystemArgument2);
                ASSERT(KeGetCurrentIrql() == DISPATCH_LEVEL);
        ...
        Prcb->DpcRoutineActive = FALSE;
        Prcb->DpcInterruptRequested = FALSE;
        ...
}
在出队Dpc对象并执行Dpc过程前后分别设置Prcb->DpcRoutineActive。这很好的解释了dpc过程中不能执行超时时间为非零等待:一旦执行等待,就会引起切换。一旦进入SwapContextInternal就会因为Prcb->DpcRoutineActive的缘故,引起蓝屏。

3.上面只解释了皮毛,为什么不能在Dispatcher_Level执行等待还是没有解释:

要解释这个,先得去看下我转载的文章:从IRQ到IRQL(PIC版),知道硬件上高IRQL怎么屏蔽低IRQL的执行。然后回过来继续往下看。不过,还得继续看KfLowerIrql。

.func @KfLowerIrql@4
_@KfLowerIrql@4:
@KfLowerIrql@4:

    /* Save flags since we'll disable interrupts */
    pushf

    /* Validate IRQL */
    movzx ecx, cl
#if DBG
    cmp cl, PCR[KPCR_IRQL]
    ja InvalidIrql
#endif

    /* Disable interrupts and check if IRQL is below DISPATCH_LEVEL */
    cmp dword ptr PCR[KPCR_IRQL], DISPATCH_LEVEL
    cli
    jbe SkipMask

    /* Clear interrupt masks since there's a pending hardware interrupt */
    mov eax, KiI8259MaskTable[ecx*4]
    or eax, PCR[KPCR_IDR]
    out 0x21, al
    shr eax, 8
    out 0xA1, al

SkipMask:

    /* Set the new IRQL and check if there's a pending software interrupt */
    mov PCR[KPCR_IRQL], ecx
    mov eax, PCR[KPCR_IRR]

    mov al, SoftIntByteTable[eax]
    cmp al, cl
    ja DoCall3

    /* Restore interrupts and return */
    popf
    ret

调用LowerIrql时,由于当前IRQL==DISPATCH_LEVEL,因此进入SkipMask。IRR寄存器会保存在执行软中断时是否有新的软中断产生。由于当前IRQL为DISPATCH_LEVEL,从SoftIntByteTabele数组中返回的值都不会大于这个值,因此,Lowerirql没有做线程切换的工作就返回了,失去一次线程调度的机会。

SoftIntByteTable:
    .byte PASSIVE_LEVEL                 /* IRR 0 */
    .byte PASSIVE_LEVEL                 /* IRR 1 */
    .byte APC_LEVEL                     /* IRR 2 */
    .byte APC_LEVEL                     /* IRR 3 */
    .byte DISPATCH_LEVEL                /* IRR 4 */
    .byte DISPATCH_LEVEL                /* IRR 5 */
    .byte DISPATCH_LEVEL                /* IRR 6 */
    .byte DISPATCH_LEVEL                /* IRR 7 */

KeWaitForSingleObject调用KiSwapThread,KiSwapThread又调用KiSwapContext和KeLowerIrql,由于KiSwapContext把出于DISPATCH_LEVEL的线程切换出去,而KeLowerIrql又没有起到因有的再次调度线程的作用,(切换进来的线程未必会唤醒等待的线程)。这倒也没什么,更重要的是,载Dispatch_Level上由KeWaitForSingleObject调用KiSwapThread,KiSwapThread再调用KfLowerIrql时,传入的NewIrql也等于Dispatch_Level

NTSTATUS
FASTCALL
KiSwapThread(IN PKTHREAD CurrentThread,
             IN PKPRCB Prcb)
{
    ....
    WaitIrql = CurrentThread->WaitIrql;
    ...
    ApcState = KiSwapContext(CurrentThread, NextThread);
    ...
    if (ApcState)
    {
        /* Lower to APC_LEVEL */
        KeLowerIrql(APC_LEVEL);

        /* Deliver APCs */
        KiDeliverApc(KernelMode, NULL, NULL);
        ASSERT(WaitIrql == 0);
    }
    KeLowerIrql(WaitIrql);
}
当新切换的线程返回时,这个新线程其实也工作在Dispatch_Level.这没什么不好的?错了,副作用还没体现出来,除非这个线程主动降低当前CPU的IRQL级别(一般都是先把优先级升到Dispatch_level,保存原irql,下次恢复时再恢复到原有的irql。然而,很不幸,原来就在DISPATCH_LEVEL上,折腾半天IRQL一直没有变化,因此KeLowerIrql始终不能起到切换线程的作用),否则IRQL一直不会下降,这个线程IRQL得不到降低,KiExitDispatch之类的也得不到执行,于是,整个系统再也没有线程切换了,变成但任务系统了(除非线程时间片用完)。

    至此,我认为很好的解释了在IRQL>=DISPATCH_LEVEL时和DPC过程中不能用KeWaitForSingleObject等待对象的原因!

你可能感兴趣的:(windows)