Implement undocumented MmProbeAndLockProcessPages routine. Based on mm-implement-mappingaddress.patch by Thomas Faber from CORE-10147, with some improvements from me.
It's badly required by FltMgr.sys driver from Windows XP/Server 2003 and closely used by a lot of apps those are depending on this driver (e. g., Avast Free Antivirus several versions, Avira Antivir Personal 8.2 etc. etc.).
Fixes several asserts from MDL support routines when the 3rd-party minifilter drivers are loading FltMgr.
CORE-14157
* [NTOS:MM] section.c: Remove unused functions
MiSetControlAreaSymbolsLoaded(),
MiLoadUserSymbols():
Added on 436edb2 (r60802). Never used.
MiSubsectionConsistent():
Added on cda03c0 (r57209). Never used.
MiGetFileObjectForSectionAddress():
Added on 635d9ca (r67810). Calls removed on 0dfd233 (r68123).
MiSetProtectionOnSection():
Added on 9f28638 (r56317). Never used.
Plus,
MmCreateArm3Section():
Add an UNIMPLEMENTED on a specific case.
* [NTOS:MM] section.c: Use static instead of NTAPI for local functions
- Stay attached while deleting the VAD node
- Acquire the appropriate working set lock when deleting a VAD node
- Both are needed for locking correctness
- Acquire the appropriate working set lock when calling MmLocateMemoryAreaByAddress
- Do not access MemoryArea without holding the lock (otherwise it can be pulled away under our feet)
- Fix range check for paged pool
These faults are handled by ARM³ and we don't need to check for a memory area. They can be recursive faults (e.g. from MiDeleteSystemPageableVm), so we might be holding the WS lock already. Passing it straight to ARM³ allows to acquire the WS lock below to look up the memory area.
This is a hack, because the kernel mode path can incur a recursive page fault with the AddressCreationLock acquired, which would lead to a recursive acquisition, once we do proper locking in MmAccessFault.
To properly fix this the PDE must be made valid, similar to the user mode path, but that is not that simple...
The code was passing 0 instead of SECTION_INHERIT::ViewUnmap (2). 0 isn't even a proper constant to be used here. It worked, because MmMapViewOfSection only compares against ViewShare (1) and treats everything else as ViewUnmap.
Now that the Memory Management is a bit more under control again,
and branching releases/0.4.15 is near,
do mute some frequent log-spam that got introduced during 0.4.15-dev'ing
regarding lazy-flushes and MM balancing.
It frequently logged even while being idle.
Slightly improve the headers of the two touched files.
No rocket-science.
As it turns out, those three functions were duplicating the same code
between each other. Reimplement these in terms of a common helper,
RtlFindExportedRoutineByName().
Indeed: MiFindExportedRoutineByName() was just MiLocateExportName()
but taking a PANSI_STRING instead of a NULL-terminated string.
A similar state of affairs also existed in Windows <= 2003, and the
MS guys also noticed it. Both routines have been then merged and renamed
to MiFindExportedRoutineByName() on Windows 8 (taking a PCSTR instead),
and finally renamed and exported as RtlFindExportedRoutineByName()
on Windows 10.
It was implemented in psmgr.c but in a recursive way. That implementation
is replaced, in the NameToOrdinal() helper, by the better non-recursive one
found in the MiLocateExportName() and MiFindExportedRoutineByName() functions.
This NameToOrdinal() helper is then called in lieu of the duplicated code
in MiLocateExportName() and MiFindExportedRoutineByName(). In addition,
one block of code in MiSnapThunk() is simplified in a similar manner.
MmGetSectionAssociation races with _MmSetPageEntrySectionSegment without sharing a lock. So we need to hold the PFN lock, until we have referenced the section segment found in the RMAP. This prevents that a section segment, which still has associated RMAPs from being deleted behind our back.
These are used in the paging path, when the page is currently in the process of being read from or written to the disk. While YieldProcessor() provides the chance to switch context to the other paging thread, it only does so, once the current thread's quantum has expired. On a single CPU system this effectively leads to busy waiting for the rest of the quantum. On SMP systems this could succeed earlier, thus reducing latency, but it would still contribute to high CPU usage, while waiting for the IO operation to complete, which is not what we want.
Using KeDelayExecutionThread() will instantly allow another thread to run, providing enough time to complete the IO operation.
Second parameter is optional, so mark it as such and check whether it was passed. Fixes a sporadic 0x24 bugcheck caused by access violation when running ReactOS on NTFS volume with WinXP ntfs.sys.
CORE-17627
When closing a file, fastfat zeroes it out from ValidDataLength up to the end of the file.
The ValidDataLength field is updated when the file content is actually written to disk.
There is currently a race between the file-close path and the page out path, leading to potential file corruptions when the zeroing happens after the memory has been flushed to disk.
Fix this by actually flushing the file to disk when unmapping files, with file lock acquired. This way, the FS driver cannot zero out the tail of the file while we're actually flushing it to disk.
