[ros-kernel] Mm problem: "Freeing locked page"

[Ge van Geldorp]

When trying to run the AbiWord installer
(http://prdownloads.sourceforge.net/abiword/setup_abiword.2-0-2.exe?down
load) I run into a problem: it bugchecks with the message "Freeing
locked page" (mm/freelist.c 741). When tracking this down, I found that
the installer tries to ReadFile() something into a buffer which is
located in the uninitialized data section (aka BSS). NtReadFile calls
(via IoBuildSynchronousFsdRequest, IoBuildAsynchronousFsdRequest and
IoPrepareIrpBuffer) MmProbeAndLockPages.
MmProbeAndLockPages makes sure the buffer pages are paged in and then
locks them. Next, it is checked whether write access is required and if
write access to the pages is already available. If not, MmAccessFault is
called to invoke the copy-on-write mechanism. Control is then
transferred to MmAccessFaultSectionView, which allocates a new physical
page, copies the contents of the existing read-only page to the new page
and (in our case) locks the new page. A check is made if the current
process is the only one interested in the old page and if so, that page
is released. Since this old page was locked in MmProbeAndLockPages, this
leads to the bugcheck.
I tried to fix it with the attached patch (which unlocks the old page if
it is determined that the new page needs to be locked) and at first that
seemed to fix the problem. However, when execution of the setup program
continues, the system runs out of swap space ("MM: Out of swap space.")
and then bug checks again, trying to trim user memory, with the
following stack trace:

KeBugCheck (BugCheckCode=0) at ke/bug.c:271
MmPageOutSectionView (AddressSpace=0xc16151e8, MemoryArea=0xc161e590,
Address=0x794000, PageOp=0xc15b8d90) at mm/section.c:1548
MmPageOutPhysicalAddress (PhysicalAddress={u = {LowPart = 39084032,
HighPart = 0}, QuadPart = 39084032}) at mm/rmap.c:307
MmTrimUserMemory (Target=5, Priority=0, NrFreedPages=0xcdc09fd4) at
mm/wset.c:55
MiBalancerThread (Unused=0x0) at mm/balance.c:339

The bugcheck message is "Private page, non-dirty but not swapped out
process 9 address 0x00794000". The (virtual) address 0x794000 is one of
the pages which was copied-on-write before, I've confirmed that the
physical address is the physical address of the r/w page allocated by
MmAccessFaultSectionView in the copy-on-write action.
Looking at the code, I get the impression that the system is trying to
tell me that there is a R/W page which is not backed by paging file, but
to be honest this is all a bit over my head. I would appreciate it if
someone with better understanding of our MemoryManager could take a look
at it.
Oh, BTW, this is all in VMware with 64Mb allocated to the virtual
machine. Problem registered in Bugzilla as #102.

Thanks, Gé van Geldorp.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: section.patch
Type: application/octet-stream
Size: 442 bytes
Desc: not available
Url : http://reactos.com:8080/pipermail/ros-kernel/attachments/20031224/b520b01d/section.obj