Where can i read everything about user buffer, that cams to driver with direct io. Who must lock that buffer. Must user program virtualLock that buffer. Must deviceiocontrol probe and lock. If yes, why. Why io maneger do not locks that buffer. can that buffer remain locked, until i will take it in filtersendnetbufferlist routine. If that buffer must not be locked inside deviceiocontrol why sometimes filtersendnetbufferlist function goes to crash, when running mmgetsystemaddressformdlsafe.
When we doing mmprobeandlockmdl, is it must be inside cikle, for taking not one mdl, but mdl chain.
The first thing to remember is that user mode code is running in ring 3, and kernel mode code in ring 0. The KM code cannot and must not trust the UM code to do anything, to have done anything, and not to do anything during the time that the call is in progress. So if your driver needs to interact with a buffer supplied from UM, you need to validate that they have supplied you a valid pointer, and you need to lock it so that it remains valid for as long as you intend to use it.
the driver decides how it would like the IO manager to present requests to it. buffered, direct or neither. There is extensive documentation on these. Here is one article, but there are many more
the choice of which kind depends on the driver. Buffered is the simplest and safest, but has the lowest performance. Method neither allows the driver total control. Direct is in between
With METHOD_DIRECT, the second buffer address you get is a kernel mode address. It has already been probed, locked, and mapped. The first buffer address is also a kernel mode address, but it is a COPY of the userās first buffer.
You should not be getting user mode addresses unless you are using METHOD_NEITHER, and there are very, very, very few good use cases for that.
Thank you. I know what buffered and direct I/O are. Thank you. I'm asking about something else. When we need to perform locking, why doesn't Windows lock the data before providing it? Mr. Tim says that the second buffer is already locked. Thank you. But where can I read more about this?
Somewhere I read that we also need to lock the page that contains the MDL structure itself. Is that true? Do we need to call VirtualLock for the user buffer before calling DeviceIoControl?
The buffers you get in the ioctl are locked. Thatās not up for debate. Now, IF that buffer happens to contain pointers to other memory, then of course that memory is not locked. That is something that is sometimes done, but is a very poor design decision.
But where can I read more about this?
Perhaps you should be reading the Microsoft documentation instead of wherever youāre getting your faulty information now.
Do we need to call VirtualLock for the user buffer before calling DeviceIoControl?
No. Where are you getting this stuff? The user application has no responsibility to āhelpā the I/O system. It is perfectly capable of managing its own memory activities.
VirtualLock is a UM API. Its purpose is to force a particular set of pages remain in the working set of a process. Despite what the documentation says, those pages can still be paged out in some cases. Unlike AWE or large pages, this is an essentially useless API.
From the point of view of any KM code, VirtualLock is also an irrelevant API. The UM process may have called it or not, and could call VirtualUnlock at anytime on anther thread. Or VirtualFree for that matter. And the pages being locked into the process working set is not a sufficient guarantee that they can be safely accessed by KM code. T
Unless you mean something unusual by ālockedā? Something besides being safe to be accessed by code in your driver?