Thread's I/O list

NTFSD
1

One of the documentations in MS says something to the effect:-
"
Typically, when the I/O Manager creates an I/O operation for a thread, the
IRP associated with that I/O is stored on a linked list off the thread (the
“ThreadListEntry” field within the IRP). This allows NT to do I/O cleanup
when the thread exits. If your driver has a completion routine which returns
STATUS_MORE_PROCESSING_REQUIRED and calls IoFreeIrp(…), the IRP might
still remain on the thread?s I/O list, which will guarantee significant
problems sometime later. It turns out that some of the I/O Manager functions
for IRP creation add the IRP to the thread?s list, while others do not.
Thus, when constructing your completion routine, it might be a good idea to
check and ensure that your IRP isn?t on the thread?s I/O list!"

I am confused about the “thread’s list”. How do I check the existence of my
allocated IRP on “thread’s I/O list”, in the iocompletion routine? Do we
know which functions from I/O manager add the IRP to thread’s list?

Thanks
Vikas

To unsubscribe send a blank email to xxxxx@lists.osr.com

2

“Vikas Ratna” wrote in message news:xxxxx@ntfsd…
>
>One of the documentations in MS says something to the effect:-
>
>“Thus, when constructing your completion routine, it might be a good idea
to
>check and ensure that your IRP isn’t on the thread’s I/O list!”
>
>I am confused about the “thread’s list”. How do I check the existence of my
>allocated IRP on “thread’s I/O list”, in the iocompletion routine? Do we
>know which functions from I/O manager add the IRP to thread’s list?
>

Well, the idea is really that you shouldn’t reclaim and return IRPs that you
didn’t originate. And this text is trying to explain to you why that’s a
bad idea, and also trying to warn you to look for documentation about which
interfaces queue requests to the current thread and which do not. If you
look at the docs for the IoBuildXxxx functions (mentioned immediately below)
you’ll see what I mean.

All of the Zw/Nt interfaces put the IRP on the thread list, as do
IoBuildDeviceIoControlRequest and IoBuildSynchronousFsdRequest, but
(notably) NOT IoBuildAsynchronousFsdRequest.

You can look at Irp->ThreadListEntry (a list head) to see if it’s (a) zero
or (b) pointing back to itself (i.e. “empty”).

What AM I doing answering File System questions??

Peter
OSR

3

Thanks. So, I will assume if I am allocating my own IRP using IoAllocate -
it would not be put in thread’s list. So, in my iocompletion routine I do
not necessarily have to check for the list before freeing the allocated Irp.

Regards.

“Vikas Ratna” wrote in message news:xxxxx@ntfsd…
>
>One of the documentations in MS says something to the effect:-
>
>“Thus, when constructing your completion routine, it might be a good idea
to
>check and ensure that your IRP isn’t on the thread’s I/O list!”
>
>I am confused about the “thread’s list”. How do I check the existence of my
>allocated IRP on “thread’s I/O list”, in the iocompletion routine? Do we
>know which functions from I/O manager add the IRP to thread’s list?
>

Well, the idea is really that you shouldn’t reclaim and return IRPs that you
didn’t originate. And this text is trying to explain to you why that’s a
bad idea, and also trying to warn you to look for documentation about which
interfaces queue requests to the current thread and which do not. If you
look at the docs for the IoBuildXxxx functions (mentioned immediately below)
you’ll see what I mean.

All of the Zw/Nt interfaces put the IRP on the thread list, as do
IoBuildDeviceIoControlRequest and IoBuildSynchronousFsdRequest, but
(notably) NOT IoBuildAsynchronousFsdRequest.

You can look at Irp->ThreadListEntry (a list head) to see if it’s (a) zero
or (b) pointing back to itself (i.e. “empty”).

What AM I doing answering File System questions??

Peter
OSR

—
You are currently subscribed to ntfsd as: xxxxx@agglut.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

“Vikas Ratna” wrote in message news:xxxxx@ntfsd…
>
> Thanks. So, I will assume if I am allocating my own IRP using IoAllocate -
> it would not be put in thread’s list. So, in my iocompletion routine I do
> not necessarily have to check for the list before freeing the allocated
Irp.
>

Precisely so, yes.

Peter

5

> I am confused about the “thread’s list”. How do I check the existence of my

allocated IRP on “thread’s I/O list”, in the iocompletion routine?

You must not do this.

Do we know which functions from I/O manager add the IRP to thread’s list?

IoBuildSynchronousFsdRequest
and
IoBuildDeviceIoControlRequest

As about

IoBuildAsynchronousFsdRequest
and
IoAllocateIrp

  • they do not put the IRP to the thread’s list.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com