In an IRP_MJ_READ pre-hook I’d like to distinguish between paging reads that populate Windows cache and paging reads that populate a userspace MapViewOfFile’d area. The only difference seems to be the presence of IRP_SYNCHRONOUS_PAGING_IO but I gather from https://osronline.com/showthread.cfm?link=253729 that that could be subject to change and should definitely not be relied upon as an indicator of origin.
Perhaps this information is lost and a paging read does not know who it is paging for.
I hope not.
Any enlightenment most gratefully received.
These are shared memory pages - you really won’t know who the “original requestor” was for the page. With that said, page faults normally block the thread that caused the fault. The only exception that comes to mind is the read-ahead logic in the Cache Manager. BUT, If you think you’ll be called when a UM process page faults, you are mistaken - most page faults don’t require doing I/O. If the page is available (via a prototype PTE in the case we’re discussing, for example) then it will be mapped into the process’ address space and you’ll be none the wiser.
So even if you could distinguish between them, I predict that whatever you think you want to do *will not work* - they are a shared resource.
If you want to “split the view” so that UM sees one thing and Cc sees another, then you need to use different SectionObjectPointer structures in the file objects. Distinct SOPs will permit distinct views. This is what NTFS does (for example) to implement transactional isolation. It’s what we do in our encryption toolkits to provide data isolation (disjoint views).