RE:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff564087(v=vs.85).aspx
So my question is, can the threads created with PsCreateSystemThread in a storage filter driver end up being paged? To combat sending a pending IRP down the stack during a completion routine that could be called at DISPATCH_LEVEL, I setup a queue and worker thread, and just signal an event (all wait times are zero) and it takes care of forwarding down. That thread is running at PASSIVE_LEVEL. If it could get paged out then would that be a problem if the IRP that was held pending (and later sent down via the worker) was related to writing to the page file?
Thanks!!
A “thread” isn’t something that is paged. The code a thread runs can be
paged and the data that code touches can be paged. Furthermore, the stack
itself can be paged if you pass the wrong arguments to KeWaitFor*.
If you are sure that you always use the right wait modes, the stack will
remain paged in. If you only call non-pageable functions, those will remain
valid. If you only touch data from non-paged pool, that will remain valid.
You will not, of course, be able to call most functions labeled as callable
at PASSIVE_LEVEL, as they may assume that they can touch paged data.
Of course, this is very much like running code in a DPC. So you might ask
yourself why you’re creating a thread. There are perfectly valid reasons to
do it. But do ask yourself whether it’s necessary.
Jake Oshins
Windows Kernel Team
This post implies no warrantees and confers no rights.
wrote in message news:xxxxx@ntdev…
RE:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff564087(v=vs.85).aspx
So my question is, can the threads created with PsCreateSystemThread in a
storage filter driver end up being paged? To combat sending a pending IRP
down the stack during a completion routine that could be called at
DISPATCH_LEVEL, I setup a queue and worker thread, and just signal an event
(all wait times are zero) and it takes care of forwarding down. That thread
is running at PASSIVE_LEVEL. If it could get paged out then would that be a
problem if the IRP that was held pending (and later sent down via the
worker) was related to writing to the page file?
Thanks!!
Beware that PsCreateSystemThread code is itself pageable. You will be able to call the function at the boot time, but don’t do that at the late runtime, if your driver manages the paging device and depends on the new thread to move forward.
right, i create it via an ioctl from user app so know I’m ok to create the thread, I was just wondering while it’s running does the code that is the worker thread itself would be paged, it doesn’t use anything that requires paging (the wait is only using zero - wait forever for event).
If the thread is not critical for performing paging path operations (I/O doesn’t rely on the thread), then there is no problem in calling PsCreateSystemThread at IOCTL request from an application.
Do you make a provision to shut down the thread if the driver needs to be
unloaded?
Creating the thread as a consequence of the app sending an ioctl is
suspect; I’d need to see more of the rationale of this design before
trying to make any conments. And what, precisely, is te purpose of te
event object? I’ve seen numerous failed attempts to implement either
mutexes and semaphores using events.
joe
right, i create it via an ioctl from user app so know I’m ok to create the
thread, I was just wondering while it’s running does the code that is the
worker thread itself would be paged, it doesn’t use anything that requires
paging (the wait is only using zero - wait forever for event).
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>Do you make a provision to shut down the thread if the driver needs to be unloaded?<
Yep, it won’t unload until everything shutdown normal.
See the other threads (messages here) about how a DPC called a completion routine, which would then try to forward a held IRP then cause a BSOD because DISPATCH_LEVEL, so worker is used to do that release.