Antwort: RE: MmProbeAndLockPages - Proble.

NTDEV
1

Hi Mark,

Thanks for your reply.

Well that won’t help, as you can’t wait at DISPATCH_LEVEL. You need to
call
MmProbeAndLockPages when you first encounter the IRP, in your
DispatchIoctl
routine, when you should be at PASSIVE_LEVEL.

That is bad. (bad design on my side )

>Also, your earlier code
>sniglet appeared to be calling both MmProbeAndLockPages and
>MmMapLockedPages, why is that? MmProbeAndLockPages ought to be sufficient
by
>itself.

So I probably misunderstood the functionality:

MmProbeAndLockPages(…) -> Locks the pages (if pageable memory)

MmMapLockedPages(…) -> Maps the locked pages into the (system) address
space so that I can access the usermode buffer.

Best Regards

Michael

2

> >Also, your earlier code

>sniglet appeared to be calling both MmProbeAndLockPages and
>MmMapLockedPages, why is that? MmProbeAndLockPages ought to be
>sufficient
by
>itself.

So I probably misunderstood the functionality:

MmProbeAndLockPages(…) -> Locks the pages (if pageable memory)

MmMapLockedPages(…) -> Maps the locked pages into the
(system) address
space so that I can access the usermode buffer.

Try MmGetSystemAddressForMdlSafe to get a kernel virtual address for the
user buffer you locked using MmProbeAndLockPages.

3

IOCTLs mostly come down at passive level and in the context of the
calling application. I say mostly because it’s a general rule which
changes stack to stack. For example, lower level drivers may get IO at
DISPATCH_LEVEL from the driver above them if the driver sends that IO in
a completion routine.

If you can rely on being a top level driver then you can do this probe
in place. Otherwise you would need to spawn the operation off to a
worker thread. Unfortunately MmProbeAndLockPages needs to be called
from the context of the application which owns the buffer, and that’s
hard to do in a worker thread unless you want to use undocumented DDIs
like KeStackAttachProcess. Makes me think we need an
IoProbeAndLockPages which would attach to the process for the IRP
automatically … I’ll have to bring that one up.

In any event, if you do post this operation off to a worker thread you
probably then can’t “wait for it to be completed” from your dispatch
routine. If you could wait you’d be at PASSIVE_LEVEL and wouldn’t have
to worry about whether to post the operation anyway. If you need to
post you’re probably at DISPATCH_LEVEL in which case you can’t block so
you need to return STATUS_PENDING and have the worker do everything.

-p

This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@sonydadc.com [mailto:xxxxx@sonydadc.com]
Sent: Friday, May 02, 2003 7:56 AM
To: NT Developers Interest List

Hi,

I’m using MmProbeAndLockPages on an Mdl built for a user mode buffer.
And after examining the DDK-DOCU again I found the following in the
MmProbeAndLockPages documentation:


Callers of MmProbeAndLockPages must be running at IRQL < DISPATCH_LEVEL
for pageable addresses, or at IRQL <= DISPATCH_LEVEL for nonpageable
addresses.

As my address is from a user mode application, it is pageable, so I must
not call this MmProbeAndLockPages(…), but where should I call it then?
Do I need to call it in a worker-thread/ workitem and wait for it to be
completed?

Best Regards
Michael

You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

4

KeStackAttachProcess is documented in IFS kit.

-Srin.

-----Original Message-----
From: Peter Wieland [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, May 02, 2003 8:43 AM
To: NT Developers Interest List
Subject: [ntdev] RE: MmProbeAndLockPages - Proble.

IOCTLs mostly come down at passive level and in the context of the
calling application. I say mostly because it’s a general rule which
changes stack to stack. For example, lower level drivers may get IO at
DISPATCH_LEVEL from the driver above them if the driver sends that IO in
a completion routine.

If you can rely on being a top level driver then you can do this probe
in place. Otherwise you would need to spawn the operation off to a
worker thread. Unfortunately MmProbeAndLockPages needs to be called
from the context of the application which owns the buffer, and that’s
hard to do in a worker thread unless you want to use undocumented DDIs
like KeStackAttachProcess. Makes me think we need an
IoProbeAndLockPages which would attach to the process for the IRP
automatically … I’ll have to bring that one up.

In any event, if you do post this operation off to a worker thread you
probably then can’t “wait for it to be completed” from your dispatch
routine. If you could wait you’d be at PASSIVE_LEVEL and wouldn’t have
to worry about whether to post the operation anyway. If you need to
post you’re probably at DISPATCH_LEVEL in which case you can’t block so
you need to return STATUS_PENDING and have the worker do everything.

-p

This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@sonydadc.com [mailto:xxxxx@sonydadc.com]
Sent: Friday, May 02, 2003 7:56 AM
To: NT Developers Interest List

Hi,

I’m using MmProbeAndLockPages on an Mdl built for a user mode buffer.
And after examining the DDK-DOCU again I found the following in the
MmProbeAndLockPages documentation:


Callers of MmProbeAndLockPages must be running at IRQL < DISPATCH_LEVEL
for pageable addresses, or at IRQL <= DISPATCH_LEVEL for nonpageable
addresses.

As my address is from a user mode application, it is pageable, so I must
not call this MmProbeAndLockPages(…), but where should I call it then?
Do I need to call it in a worker-thread/ workitem and wait for it to be
completed?

Best Regards
Michael

You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@nai.com
To unsubscribe send a blank email to xxxxx@lists.osr.com