Re: Determining Process ID with shared memory

NTFSD
1

Hi Maxim,<?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” /><o:p></o:p>

<o:p> </o:p>

Thank you for the reply. Anything I can do to replace locking the pages would be very good. Just so I’m clear, you’re saying that the IOCTL IRP (MJ_SYSTEM_CONTROL?) that makes the shared memory request should use METHOD_xxx_DIRECT (IN for output and OUT for input), and that pending this IRP in the dispatch handler will effectively lock the memory? Forgive my ignorance, but if Process A, say, makes a shared memory request, and I pend its IRP, and Process B comes along with the same request, and then Process A abnormally terminates, how do I resolve which IRP to cancel? You say to cancel all pending IRP’s, but then wouldn’t
that effectively unlock Process B’s shared memory? I’m obviously missing something here.<o:p></o:p>

<o:p> </o:p>

-Mike<o:p></o:p>

<o:p> </o:p>

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Wednesday, June 28, 2006 11:43 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Determing Process ID with shared memory

<o:p> </o:p>

> I have a filter driver that can potentially have any number of processes set<o:p></o:p>

up its<o:p></o:p>

>own shared memory. I segregate the separate locked pages by using the<o:p></o:p>

>process ID of the requesting processs using PsGetCurrentProcessId(). When<o:p></o:p>

<o:p> </o:p>

You can lock the pages by pending the METHOD_xxx_DIRECT IOCTL IRP, instead of<o:p></o:p>

doing your own MmProbeAndLockPages.<o:p></o:p>

<o:p> </o:p>

If this IRP will be cancellable - then its completion at cancellation will<o:p></o:p>

automatically do the job.<o:p></o:p>

<o:p> </o:p>

In MJ_CLEANUP handler, just cancel all pending IRPs.<o:p></o:p>

<o:p> </o:p>

Maxim Shatskih, Windows DDK MVP<o:p></o:p>

StorageCraft Corporation<o:p></o:p>

xxxxx@storagecraft.com<o:p></o:p>

http://www.storagecraft.com<o:p></o:p>

<o:p> </o:p>

<o:p> </o:p>

—<o:p></o:p>

Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17<o:p></o:p>

<o:p> </o:p>

You are currently subscribed to ntfsd as: xxxxx@spursuits.com<o:p></o:p>

To unsubscribe send a blank email to xxxxx@lists.osr.com<o:p></o:p>

2

>be very good. Just so I’m clear, you’re saying that the IOCTL IRP

(MJ_SYSTEM_CONTROL?)

MJ_DEVICE_CONTROL

that makes the shared memory request should use METHOD_xxx_DIRECT (IN
for output and OUT for input), and that pending this IRP in the dispatch
handler
will effectively lock the memory?

Yes, the locked memory MDL will be at Irp->MdlAddress

Process A abnormally terminates, how do I resolve which IRP to cancel?

Any process termination includes thread rundown, which automatically cancels
all IRPs belonging to a thread. All of this is done by the kernel itself, you
just need to make the IRP cancellable.

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

3

I’ve implemented this and it seems to work pretty well. I just had a couple of questions. Should I enqueue the pended IRP to my device extension or is this not needed? Also, do I need to remove the IRP from &Irp->Tail.Overlay.ListEntry in the cancel callback, or does the I/O manager handle this? Lastly, do I need to call IoSetCancelRoutine(Irp, NULL) in the cancel callback? In the checked build of the filter driver I’m not doing any of the above and it seems to work fine, but I wanted to make sure I got it right. Thanks.

-Mike

4

On Tue, 18 Jul 2006 17:28:16 -0400 (EDT), xxxxx@hotmail.com wrote:

I’ve implemented this and it seems to work pretty well. I just had a couple of questions. Should I enqueue the pended IRP to my device extension or is this not needed? Also, do I need to remove the IRP from &Irp->Tail.Overlay.ListEntry in the cancel callback, or does the I/O manager handle this? Lastly, do I need to call IoSetCancelRoutine(Irp, NULL) in the cancel callback? In the checked build of the filter driver I’m not doing any of the above and it seems to work fine, but I wanted to make sure I got it right. Thanks.

-Mike

Well you should definitely enqueue the IRP in one of your queues. The
reason being that if the device that you are monitoring gets surprise
removed you can go thru this queue and complete all the pending
requests. As for managing cancel, I would look at using the
Cancel Safe Queue routines (IoCsq) They make managing cancel a lot
easier.

Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, INc.

5

>needed? Also, do I need to remove the IRP from &Irp->Tail.Overlay.ListEntry
in

the cancel callback, or does the I/O manager handle this?

IO manager does this.

Lastly, do I need to call IoSetCancelRoutine(Irp, NULL) in the cancel
callback?

No, it is already removed.

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