Don't pass MM_DONT_ZERO_ALLOCATION to MmAllocatePagesForMdlEx()...
...in __AllocatePages()
See commit
4f85d004 "Replace uses of MmAllocatePagesForMdlEx in
__AllocatePage" in XENVIF for more background.
In summary, it is to avoid BSOD 139 1e with a stack similar to the following:
nt!KeBugCheckEx
nt!KiBugCheckDispatch+0x69
nt!KiFastFailDispatch+0xd0
nt!KiRaiseSecurityCheckFailure+0x30e
nt!KiAcquireThreadStateLock+0x11fa90
nt!KeSetIdealProcessorThreadEx+0xd0
nt!MiZeroInParallelWorker+0x115016
nt!MiZeroInParallel+0x11c
nt!MiInitializeMdlBatchPages+0x2ae
nt!MiAllocatePagesForMdl+0x192
nt!MmAllocatePartitionNodePagesForMdlEx+0xc9
nt!MmAllocatePagesForMdlEx+0x4d
These bugchecks have been observed in recent updates of Server 2019.
This patch, rather than replacing calls to MmAllocatePagesForMdlEx() with
calls to MmMapLockedPagesSpecifyCache(), just avoids passing
MM_DONT_ZERO_ALLOCATION to work round the bug.
The patch instead passes MM_ALLOCATE_FULLY_REQUIRED, which arguably should
have always been passed for allocations larger than a single page. It also
fixes a formatting issue.
NOTE: Nothing in XENIFACE currently calls __AllocatePages() so this patch is
not strictly necessary. However, in case a caller is added in future,
it is best to keep util.h in sync with the other drivers.
Reported-by: Jan Bakuwel <jan.bakuwel@gmail.com>
Signed-off-by: Paul Durrant <pdurrant@amazon.com>