何为TopLevelIrp

TopLevelIrp是当前内核线程结构中的一个指针，可以是一个数值标识（ULONG_PTR），也可以是指向一个内存块的指针（内核IRP结构或用户自定义结构），其目的就是给文件系统驱动记录当前线程其内核栈最早传入且正在处理的I/O请求。因为处理一个I/O请求的过程中可能引入新的I/O，这样就会导致文件系统的重入（嵌套调用），重入问题很有可能会带来对资源依赖的死锁，所以文件系统驱动需要在重入的情况也能甄别出当前正处理的请求是不是最早的，即当前线程内核栈及资源的占用情况，从而采取不同的策略以避免死锁的发生。在时间顺序上最早的请求，从调用栈上来看就是处于最高地址（最高位置）的请求。

TopLevelIrp在内核线程结构中的定义如下：

typedef struct _ETHREAD {
    KTHREAD Tcb;
    ...
    //
    //  File Systems
    //

    ULONG_PTR TopLevelIrp;  // either NULL, an Irp or a flag defined in FsRtl.h
    struct _DEVICE_OBJECT *DeviceToVerify;
    ...
} ETHREAD, *PETHREAD;

TopLevelIrp及DevcieToVerify等域均是留给文件系统驱动专用的，可以作为一个当前线程的环境变量或各层调用栈间的共享变量。

系统操作函数

ETHREAD是内核私有结构，系统内核提供给外部组件（主要是文件系统驱动）两个接口：

函数	功能
VOID IoSetTopLevelIrp(IN PIRP Irp);	设置（改变）当前线程的TopLevelIrp值
PIRP IoGetTopLevelIrp(VOID);	读取当前线程的TopLevelIrp值

TopLevelIrp的操作过程

文件系统驱动与操作系统内核组件：Cache Manager（缓存子系统）、Virtual Memory Manager（虚拟内存管理子系统）及I/O Manager （I/O子系统）间交互相非常紧密且调用关系也非常复杂，调用嵌套及重入的情形非常多，分辨并正确处理不同的重入情景正是文件系统驱动不得不面对的复杂难题。

TopLevelIrp就是为了解决这个问题而设计的。其最直接的操纵及访问者也是文件系统驱动，因为用户层I/O请求最初的响应都是由I/O Manager直接传给文件系统的。文件系统驱动在响应过程中会调用操作系统的其它子系统，在调用前会针对TopLevelIrp做不同的设置。另外还有几种常见情况，如Cache Manager及Virtual Memory Manager会根据内存压力来发起I/O操作，所以内核子系统也需要修改、设置TopLevelIrp域以标识出本次I/O操作的发起者。

IoGetTopLevelIrp()返回值（当前线程的TopLevelIrp域）	含义
FSRTL_CACHE_TOP_LEVEL_IRP	由缓存管理器触发的i/o请求：延迟写（Lazy-write）或预读（Readahead）
FSRTL_MOD_WRITE_TOP_LEVEL_IRP	由系统脏页回写线程触发的写请求（在MiMappedPageWriter回写映射文件的脏页时）
FSRTL_FAST_IO_TOP_LEVEL_IRP	由I/O Manager及文件系统自身处理Fast i/o请求时设置
FSRTL_FSP_TOP_LEVEL_IRP	通常由文件系统本身触发，用以标识文件系统驱动自身的i/o处理线程（Workitem线程池）。由于此情况下TopLevelIrp完全由文件系统自已管理，IRP或私有结构，通常由文件系统自已构造并使用

操作场景

用户态切换到内核态这是最通常的情形，即请求直接来自于用户，用户请求经过syscall之后到达I/O Manager，而后I/O Manager会构造Irp并直接传给文件系统。文件系统最通常的做法就是将当前的Irp设为TopLevelIrp。文件系统当然也可以用自己私有的结构，因为此线程在Irp没有完成之前将完全由文件系统所控制，TopLevelIrp也只有文件系统驱动会查询。
Fast I/O 用户态的请求通过syscall到达I/O Manager后，I/O Manager发现文件已经被打开过且可以通过文件系统驱动所提供的callback直接来处理这个请求，不必从内存池中分配Irp等结构。文件系统被调用后又会调用内核所提供的文件系统支持函数（FsRtl...），此操作将有可能涉及Cache Manager、VM，或重入文件系统驱动等，所以文件系统支持函数会设置TopLevelIrp为FSRTL_FAST_IO_TOP_LEVEL_IRP以标示出最初的请求响应是通过Fast I/O来做的。
文件系统自身的Workitem线程类似第一种情形（用户态切换到内核态），Workitem线程本身是由文件系统发起并且是文件系统所私有的内核线程，但Workitem中的操作却是有可能重入文件系统的（这个由文件系统的设计决定）。 TopLevelIrp的值可以由文件系统驱动自行决定，如可以设为FSRTL_FSP_TOP_LEVEL_IRP，也可以设为此Workitem当前要处理的请求Irp，也可以设成是文件系统驱动的私有结构。
缓存管理器：延迟写 Cache Manager的Lazy-write操作（延迟写）是在Cache Manager私有的内核线程中执行的。在调用文件系统进行I/O操作之前会设置TopLevelIrp为FSRTL_CACHE_TOP_LEVEL_IRP，因为Lazy-write操作会通过Cache Manager callback来获取相应的锁资源，并且最终的I/O操作总要由文件系统来完成。
虚拟内存管理器：MiMappedPageWriter 内存映射文件的I/O不会经过Cache Manager，而是由Virtual Memory Manager直接处理的，并且是在Virtual Memory Manager私有的内核线程中做的，此线程的处理函数就是MiMappedPageWriter。同Cache Manager延迟写的流程类似，最终的I/O操作总要由文件系统来完成，所以移交控制权之前，VM会将当前线程的TopLevelIrp设置为FSRTL_MOD_WRITE_TOP_LEVEL_IRP，以通知文件系统驱动当前请求是由VM发起的。

不同文件系统驱动的处理差异

前面说过TopLevelIrp的读操作及检测只有文件系统驱支在做，虽然其设置可以是多方的。对于文件系统驱动来说，TopLevelIrp的具体值是由文件系统自己来解释的，所以针对 FSRTL_FSP_TOP_LEVEL_IRP，不同的文件驱动对TopLevelIrp的处理也不尽相同：

文件系统驱动	TopLevelIrp所指向的结构
FastFat	nt!_IRP
Cdfs	cdfs!_THREAD_CONTEXT
Ntfs	ntfs!_TOP_LEVEL_CONTEXT

案例分析

TopLevelIrp的设置是一项精巧的手艺活，稍有不慎就会阴沟里翻船，下面就介绍两个开发中曾遇到的案例：

NTFS：Valid Data Length的设置

Ntfs文件系统驱动在其内部维护着每个数据流的Valid Data Length（VDL，有效数据长度），且VDL是管理于Ntfs的私有结构中的。VDL的更新一般是在cached i/o过程中做的。但实际操作中我们有个特殊的需求：要截获所有的cached i/o请求，只会通过paging i/o请求和Ntfs文件系统驱动交与，这样操作的后果就导致VDL不能被正常更新，虽然数据已经写到了磁盘上但是当试图读回数据的时候，Ntfs会根据VDL对数据进行清零化处理。

最后的解决办法也是一个不得已的投巧的办法：将我们的paging writing 请求模拟成mmap i/o (memory mapping i/o)，即映射文件的数据刷写方式。mmap i/o操作本身就是个top level操作，并且也是仅有的top level paging i/o的情形。所以针对mmap i/o，Ntfs会更新VDL，这也是唯一的可以更新VDL的机会。

CDFS: 换了光盘但不能正确加载

这个问题比较妖怪，本来以为是文件系统过滤驱动的问题，但仔细分析过滤驱动又没有发现可疑点，最后经过代码对比及对WDK中cdfs的动态调试才定位到问题症结：原来是top level irp的问题。

我们都知道文件系统对于可移动设备及可移除介质设备都会有个检验（即verify）操作，但cdfs的verify操作会检测当前的TopLevelIrp状态，并根据这个状态来决定是否继续verify操作。当我们设置了TopLevelIrp之后，cdfs会认为它不在最高的调用栈上，故直接跳过了verify操作，最终就导致了换光盘后新光盘无法被正常识别的问题。

参考链接

<本文用时约5小时>