Hi, I have developed fsd for a while, but I still confused about IRP_PAGING_IO.
From my observation,
IRP_WRITE_OPERATION - IRP_PAGING_IO means write to page instead of writing to file sys;
IRP_READ_OPERATION - IRP_PAGING_IO means read from filesys instead of read from page.
Are my opinions correct?
There are a couple of ways to approach this question. Let’s first approach it operationally:
* This bit indicates that one of the Paging I/O functions in the I/O Manager have been invoked (by MM) to fill in or write out physical pages that contain data that is stored by the file system driver. This includes IoPageRead, IoSynchronousPageWrite and IoAsynchronousPageWrite
* This bit indicates (to a filter or a file system) that there is an MDL describing the physical pages. This doesn’t necessarily mean that there is a mapping (to a virtual address) for those pages (MmGetSystemAddressForMdlSafe can be used to create one if necessary, though it’s best to be avoided unless necessary).
* This bit indicates (again to a filter or a file system) that the UserBuffer address *may not be a valid address*. It turns out that it needs to match what’s in the MDL but there’s no guarantee that it’s actually mapped at that address. I mention this in my file systems class because it’s a subtle bug I’ve seen multiple times over the years.
* This bit indicates that a filter wishing to use that buffer MUST use the MDL (if you don’t the OS will give you the frowny face of death - FFOD - in Windows 8/8.1). This is because building a new MDL for the same physical pages risks marking the pages as dirty and that can cause them to be WRITTEN, which is definitely not what you want.
* An IRP_MJ_READ or IRP_MJ_WRITE where this bit is set will not use an APC to perform completion of the original I/O - the I/O Manager will directly set the event object in the IRP to signal back to the original thread that the I/O is completed.
* When tearing down an IRP, the I/O Manager *will not free* the Irp->MdlAddress when this bit is set. That’s because the I/O Manager views the MDL as belonging to the Memory Manager.
Now let’s approach it conceptually:
For read, this indicates that the page is being read via the demand page fault mechanism, and rather than the virtual address of a buffer we are given an MDL that describes the newly allocated physical pages that will eventually be used to resolve the virtual address at which the fault occurred.
For write, this indicates that something within the virtual memory system (Mm or Cc) is requesting that the data within the given physical pages be written back to storage by the file system driver. Again, there is not necessarily any valid virtual address mapping. Writing dirty pages back to their storage location is an essential part of how the Memory Manager reclaims pages. For Cc, the write-back is part of write-behind cache logic.
Mm doesn’t care if dirty pages EVER get written back per-se. It cares that there aren’t “too many” dirty pages. But it’s content to have a handful of old dirty pages sitting around in memory.
Cc doesn’t care about page allocation, usage, working sets, etc. It cares that data in the file system write-behind cache doesn’t stick around “too long”.
Tony
OSR
Thank you for your answer, I get the point.
I still have a question, there should page file(s) on the storage right?(used for the temporary storage of physical pages)
How can I distinguish whether the IRP_MJ_WRITE wants to write to the page file(s) on disk or a normal file on disk? The IRP_PAGING_IO & IRP_MJ_WRITE means only write physical pages to page file(s) on disk or write to normal files on disk?
For operations destined for the paging file, the file name of the object
will be pagefile.sys, for operations targeted at a ‘normal’ file, the
objects name will be something other than pagefile.sys. I say ‘normal’
since the paging file is a file, with one distinguishing aspect, from a
file system filter drivers’ perspective, is the open for a paging file
will have the IO_OPEN_PAGING_FILE flag set.
The flags can be set for paging which occurs to either the paging file
or a ‘normal’ file.
Pete
On 5/16/2014 8:48 PM, xxxxx@serpurity.com wrote:
Thank you for your answer, I get the point.
I still have a question, there should page file(s) on the storage right?(used for the temporary storage of physical pages)
How can I distinguish whether the IRP_MJ_WRITE wants to write to the page file(s) on disk or a normal file on disk? The IRP_PAGING_IO & IRP_MJ_WRITE means only write physical pages to page file(s) on disk or write to normal files on disk?
NTFSD is sponsored by OSR
OSR is hiring!! Info at http://www.osr.com/careers
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Also FltMgr has a function to check for pagefile.
“Peter Scott” wrote in message news:xxxxx@ntfsd…
>
> For operations destined for the paging file, the file name of the object
> will be pagefile.sys, for operations targeted at a ‘normal’ file, the
> objects name will be something other than pagefile.sys. I say ‘normal’
> since the paging file is a file, with one distinguishing aspect, from a
> file system filter drivers’ perspective, is the open for a paging file
> will have the IO_OPEN_PAGING_FILE flag set.
>
> The flags can be set for paging which occurs to either the paging file
> or a ‘normal’ file.
>
> Pete
>
> On 5/16/2014 8:48 PM, xxxxx@serpurity.com wrote:
>> Thank you for your answer, I get the point.
>> I still have a question, there should page file(s) on the storage right?(used for the temporary storage of physical pages)
>> How can I distinguish whether the IRP_MJ_WRITE wants to write to the page file(s) on disk or a normal file on disk? The IRP_PAGING_IO & IRP_MJ_WRITE means only write physical pages to page file(s) on disk or write to normal files on disk?
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> For our schedule of debugging and file system 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
>
> –
> Kernel Drivers
> Windows File System and Device Driver Consulting
> www.KernelDrivers.com
> 866.263.9295
>
>
>
I couldn’t find a filter manager function that does this - I could be missing it, but it didn’t show up in the documentation or a search of fltKernel.h for me.
There is an FsRtl function that determines this: FsRtlIsPagingFile (http://msdn.microsoft.com/en-us/library/windows/hardware/ff546873(v=vs.85).aspx) but note that it isn’t present on old OS platforms.
The other technique I’ve seen is to watch for the SL_OPEN_PAGING_FILE operation in the IRP_MJ_CREATE handler and track this state information in that fashion. This only works if your filter loads before the paging file is opened, of course.
Note that there is *absolutely no requirement* the file be called pagefile.sys. We’re used to seeing this because this is the name the OS utilities prefer when creating the registry information.
See: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management, specifically the existing paging files and paging files values. These values are used to control the placement and name of the paging file.
I mention this because some people have in fact figured out that they can use the special properties of the paging file for creative purposes (e.g., identifying the physical locations of the file on the drive as is done for the crash dump handler).
Tony
OSR
Thank you very mush, I understand it 