>>> Massively stupid question: Could anybody explain why you’d want to
>> MmProbeAndLockPages for a non-pageable address?
> I’m trying to use pageable memory because my IRP will potentially be
>pended by lower altitude filters for long periods of time, so I call
>ExAllocatePoolWithTag(PagedPool, … ) in the PreOpCallback. That’s
>why I’m trying to lock it in my asynch callback.
You’ve missed the point of the question. If the MDL describes a
non-pageable address, MmProbeAndLockPages should be completely
redundant, unless I’ve misinterpreted the docs and their usage of the
phrase “non-pageable address”.
I don’t see anything in the documentation that says an MDL describes a
non-pageable address.
It can describe either paged memory or non-paged memory.
From the topic “Using MDLs” it says “The system uses a memory
descriptor list (MDL) structure to represent the physical page layout
for a virtual memory buffer.” Then further down it says “For pagable
memory, the correspondence between virtual and physical memory is
temporary, so the page number array is valid only under certain
circumstances. Call MmProbeAndLockPages to lock the pagable memory into
place and initialize the page number array for the current layout.” The
MmProbeAndLockPages command, as its output, updates an MDL (which must
be pre-allocated) that describes the physical layout of the now-locked
buffer.
We’re in agreement on this point, but the MmPALP docs also say: “Callers
of MmProbeAndLockPages must be running at IRQL <= APC_LEVEL for pageable
addresses, or at IRQL <= DISPATCH_LEVEL for nonpageable addresses.”
Maybe we’re both arguing the same point, although I think it’s
important to semantically distinguish between a “non-pageable” address
(what you’re referring to) and a “locked pageable” address (what I’m
referring to).
It is important to distinguish between the two, but you have neither of
these things in your async callback. You have an MDL that describes
unlocked pageable memory.
Let’s back up a second here and take a look at three scenarios:
I:
- malloc a buffer from the paged pool at APC_LEVEL or PASSIVE_LEVEL
- Get an MDL for it
- In the blink of an eye your buffer gets paged out.
- you find yourself at DISPATCH_LEVEL with this MDL which describes
memory that is no longer paged in.
- MmPALP… ()
- Bugcheck! The memory described by the MDL is paged memory and it
can’t be paged back in because of IRQL
II:
- malloc a buffer from the non-paged pool at <= DISPATCH_LEVEL
- Get an MDL for it
- War breaks out
- years pass, this discussion fades from memory. Incredibly, your
computer stays up the whole time.
- You rediscover your computer and find yourself at DISPATCH_LEVEL.
- MmPALP… () (whether or not this serves any purpose was my original
question)
- it works, because the memory still hasn’t been paged out, and never
will be.
III:
- malloc a buffer from the paged pool at APC_LEVEL or PASSIVE_LEVEL
- Get an MDL for it
- MmPALP ()
- You’re abducted by aliens
- years pass, this discussion fades from memory. Incredibly, your
computer stays up the whole time.
- The aliens return you and you rediscover your computer and find
yourself at DISPATCH_LEVEL.
- MmPALP… () (redundantly, though you still have to make a matched
call to unlock the memory)
- it works, because the memory still hasn’t been paged out (because
it’s locked), and won’t be until you allow it to be.
Situation I is (maybe) what you’re seeing happen.
Situation II is what the sample code with the WDK does.
Situation III is the other possible situation where you can access the
memory in your async callback without getting yourself to either
PASSIVE_LEVEL or APC_LEVEL.
The point is that the mdl describes a buffer allocated from the paged
pool, and that buffer hasn’t been locked when you were at PASSIVE_LEVEL
or APC_LEVEL, you’re not going to be able to lock it at DISPATCH_LEVEL.
If the pages are locked at PASSIVE or APC, then the MDL will still be
useful at DISPATCH, and is just as good as an MDL describing memory from
the non-paged pool.
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com