Hello,
I completely agree from different threads to use IoAllocateIRP. Though I have couple of questions as there is a legacy code.
* It is expected to free the MDL and Free the IRP in completion. In case it is not done and simple return Status success from completion routine. Would IO manager free the Irp and MDL(Direct IO)?
* Whether it is mandatory to create page pool buffer for IoBuildAsynchronousFsdRequest? I am concerned it might be not dealing with non page pool.
No, the I/O Manager won’t free them.
Well, it really depends. You are sending an I/O request to another driver,
what do they expect to receive? The API doesn’t care if the buffer is
non-paged or not, it’s a matter how the request is processed.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntdev…
Hello,
I completely agree from different threads to use IoAllocateIRP.
Though I have couple of questions as there is a legacy code.
* It is expected to free the MDL and Free the IRP in completion. In case it
is not done and simple return Status success from completion routine. Would
IO manager free the Irp and MDL(Direct IO)?
* Whether it is mandatory to create page pool buffer for
IoBuildAsynchronousFsdRequest? I am concerned it might be not dealing with
non page pool.
I wanted to explicitly send NonPagePool memory as later wanted to access at Higher IRQL.
IoBuildAsyncFsdRequest might have attempted to Allocate MDL and Probe_Lock which is internal to the function. In such scenario I would require to handle completion in similar manner to page pool i.e MmUnlockPages, IoFreeMdl.
As stated in one of the OSR thread to call unmap in case NonPagePool is called with Probe_Lock
Please correct me.
Unless you terminate processing prematurely (by setting a completion routine and then not allowing the I/O Manager to complete the IRP), it will be cleaned up properly. The I/O Manager has subtle behavior around IRPs and MDL cleanup (paging I/O MDLs are not cleaned up because they aren’t created by the I/O Manager, they are passed in by the Memory Manager, for example). But in this case the I/O Manager will mark the IRP to indicate that it created the MDL and thus must clean it up when done.
Having said that, we have seen complex issues in this area around device memory in some versions of Windows. But I believe these have all been resolved since at least Windows 7.
Tony
OSR
If you use IoBuildAsynchronousFsdRequest, you are responsible for cleaning
up and freeing the IRP. This includes tearing down the MDL (if there is on)
and freeing the IRP. See the FASTFAT code for an example.
So, send a non-paged pool buffer with your request. When the request
completes, unlock and free MDL if there is one. Done.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntdev…
I wanted to explicitly send NonPagePool memory as later wanted to access at
Higher IRQL.
IoBuildAsyncFsdRequest might have attempted to Allocate MDL and Probe_Lock
which is internal to the function. In such scenario I would require to
handle completion in similar manner to page pool i.e MmUnlockPages,
IoFreeMdl.
As stated in one of the OSR thread to call unmap in case NonPagePool is
called with Probe_Lock
Please correct me.
>Unless you terminate processing prematurely (by setting a completion
routine and then not allowing the I/O Manager to complete the >IRP), it
will be cleaned up properly
The OP is using IoBuildAsynchronousFsdRequest. The resulting IRP isn’t
threaded, thus you *have* to reclaim the IRP in the completion routine
(which means you are responsible for the cleanup).
-scott
OSR
@OSRDrivers
“Tony Mason” wrote in message news:xxxxx@ntdev…
Unless you terminate processing prematurely (by setting a completion routine
and then not allowing the I/O Manager to complete the IRP), it will be
cleaned up properly. The I/O Manager has subtle behavior around IRPs and
MDL cleanup (paging I/O MDLs are not cleaned up because they aren’t created
by the I/O Manager, they are passed in by the Memory Manager, for example).
But in this case the I/O Manager will mark the IRP to indicate that it
created the MDL and thus must clean it up when done.
Having said that, we have seen complex issues in this area around device
memory in some versions of Windows. But I believe these have all been
resolved since at least Windows 7.
Tony
OSR
Thanks Tony and Scott for inputs. It was helpful