Use METHOD_BUFFERED if your buffers are small.
METHOD_NEITHER is dangerous if you are not aware of how to handle raw
user mode buffers. If your input buffer is really large & you have to
return output via another buffer, you have measured the impact & know
the cost of using the buffered access is high, you can use
METHOD_NEITHER. If you are in the originating process’ context, you can
just do a try-except() around access to the buffer, and do not need to
lock the pages down. Howeve you MUST do a ProbeForRead() for the input
buffer and ProbeForWrite() for the output buffer within the try-except()
before you access the buffers (user mode can pass down a buffer address
that is a kernel-mode address, so the probe is required).
I’m pretty sure all this is documented, I’ll try to dig up the pointer
to the docs
Ravi
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: Bi Chen [mailto:xxxxx@AppStream.com]
Sent: Monday, September 30, 2002 6:38 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Weird DeviceIoControl bug in win2k (blame the Io
Manager for that ?)
Thanks for the explanation, Max and Rev. I could not find where the DDK
doc says that. With your explaination, I believe it is by design, using
Output buffer as the second input buffer, using the input buffer to
specify private information of the second input buffer.
It looks like DeviceIoControl does not foot my bill to piggy-pack some
data on the way back to user mode, I try to avoid page probe and lock
the "output buffer (to DeviceIoControl) since it is usally no more than
32 byte. The best way may be to use METHOD_NEITHER and almost documented
KAPC. Shame on Microsoft not to give us an easy way out.
Bi
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Monday, September 30, 2002 5:45 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Weird DeviceIoControl bug in win2k (blame the Io
Manager for that ?)
This is by design.
Both direct IOCTL methods (they differ in IoxxxAccess parameter to
MmProbeAndLockPages only) put InputBuffer to AssociatedIrp.SystemBuffer,
and OutputBuffer to MdlAddress.
AssociatedIrp.SystemBuffer is never copied back to user.
The only difference between 2 IOCTLs is how the OutputBuffer is
locked. One method (don’t remember off-head what namely) locks
OutputBuffer for write, thus providing a usual request/response
semantics. Another locks OutputBuffer for read, in this case,
OutputBuffer is second input buffer and there is no output buffer.
Such an IOCTL provides a “write qualified with some small additional
data” semantics, it can be useful.
Max
----- Original Message -----
From: Bi Chen
To: NT Developers Interest List
Sent: Tuesday, October 01, 2002 4:15 AM
Subject: [ntdev] Weird DeviceIoControl bug in win2k (blame the Io
Manager for that ?)
Hi,
I encountered a weird DeviceIoControl Bug. I wrote a driver that I have
a special need to send large chuck of data to kernel mode driver but
receive some small piggy-pack data in return. The driver is opened with
GENERIC_READ | GENERIC_WRITE flag.
I use
#define APPSD_IOCTL_DIRECTTOUT_REQ CTL_CODE(FILE_DEVICE_UNKNOWN,
APPS_DEVICE_1STFUNC + 3, METHOD_OUT_DIRECT,
FILE_READ_DATA|FILE_WRITE_DATA)
^^^^^^^^^^^^^^^^^
as the ioctl code.
In my code
DWORD cbRet = 0;
BOOL bRet = DeviceIoControl(m_hDriver, APPSD_IOCTL_DIRECTTOUT_REQ,
request, cbreq, reply, cbrep, &cbRet,
pOvlapped);
However, in my driver, I found out that IO Manager always
MmPageProbeAndLock the “reply” and set
Irp->MdlAddress to that memory.
Then I try the other way around even though DDK doc says otherwise, I
change the ioctl code to
#define APPSD_IOCTL_DIRECTTOUT_REQ CTL_CODE(FILE_DEVICE_UNKNOWN,
APPS_DEVICE_1STFUNC + 3, METHOD_IN_DIRECT,
FILE_READ_DATA|FILE_WRITE_DATA)
^^^^^^^^^^^^^^^^
The result is the same. Irp->MdlAddress still points to the reply.
The I revised input buffer and output buffer role
bRet = DeviceIoControl(m_hDriver, APPSD_IOCTL_DIRECTTOUT_REQ,
reply, cbrep, request, cbreq, &cbRet,
pOvlapped);
Now Irp->MdlAddress points to where I want. The problem is, whatever I
worte in the
Irp->AssociatedIrp.SystemBuffer in the driver is not copied to the reply
buffer in user mode.
Uh…, either I was working to hard to become dizzy headed or Microsoft
kernel guy did something really weird, something like
if(ioctl&3)
{
mdl = IoAllocateMdl(…);
MmPageProbeAndLock(mdl, UserMode, IoModifyAcess);
}
I believe it could be beause my head is dizzy and spining. First time
use DeviceIoControl to pass large data. I could not believe Io Manager
has such a bug.
Thanks.
Bi
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to %%email.unsub%%