[haiku-commits] r35195 - haiku/trunk/src/system/kernel/vm

  • From: ingo_weinhold@xxxxxx
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Wed, 20 Jan 2010 10:00:38 +0100 (CET)

Author: bonefish
Date: 2010-01-20 10:00:38 +0100 (Wed, 20 Jan 2010)
New Revision: 35195
Changeset: http://dev.haiku-os.org/changeset/35195/haiku
Ticket: http://dev.haiku-os.org/ticket/5138

Modified:
   haiku/trunk/src/system/kernel/vm/vm.cpp
Log:
vm_get_page_mapping(): The translation map wasn't locked. For x86 the
function is used only in one place and the missing locking would be harmless
if it weren't for the per translation map physical page mapper. It is used to
map the page table for the lookup. Concurrent access could corrupt its data
structures, or, just as bad, the unlocked Query() could remap the page table
used by a concurrent Map() or Unmap(), which would then manipulate the
wrong page table.
Potentially messing up kernel memory, this bug could obviously cause all
kinds of kernel crashes and weird behavior. E.g. ticket #5138 is a likely
candidate, as are triple faults.


Modified: haiku/trunk/src/system/kernel/vm/vm.cpp
===================================================================
--- haiku/trunk/src/system/kernel/vm/vm.cpp     2010-01-20 05:01:28 UTC (rev 
35194)
+++ haiku/trunk/src/system/kernel/vm/vm.cpp     2010-01-20 09:00:38 UTC (rev 
35195)
@@ -2090,9 +2090,12 @@
        if (addressSpace == NULL)
                return B_BAD_TEAM_ID;
 
+       VMTranslationMap* map = addressSpace->TranslationMap();
+
+       map->Lock();
        uint32 dummyFlags;
-       status_t status = addressSpace->TranslationMap()->Query(vaddr, paddr,
-               &dummyFlags);
+       status_t status = map->Query(vaddr, paddr, &dummyFlags);
+       map->Unlock();
 
        addressSpace->Put();
        return status;


Other related posts: