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. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35195 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
parent
28e27159b9
commit
15779f70b9
@ -2090,9 +2090,12 @@ vm_get_page_mapping(team_id team, addr_t vaddr, addr_t* paddr)
|
||||
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;
|
||||
|
Loading…
Reference in New Issue
Block a user