* Reverted r32216 (by mmlr): it's not a good idea to access a variable on the

stack after that has just been changed, and does not contain the data one
  would assume.
* This fixes the leaking the vm_translation_map_arch_info objects, and thus
  bug #4957.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34090 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
Axel Dörfler 2009-11-17 14:56:51 +00:00
parent 3917e20402
commit 931d8b07e8
1 changed files with 5 additions and 4 deletions

View File

@ -383,6 +383,10 @@ arch_thread_context_switch(struct thread *from, struct thread *to)
atomic_and(&activeMap->active_on_cpus, ~((uint32)1 << cpu));
atomic_or(&toMap->active_on_cpus, (uint32)1 << cpu);
activeMap->RemoveReference();
// this might causes the map to be deferred deleted - ie. it won't
// be deleted when it is still in use
// assign the new map to the CPU
toMap->AddReference();
cpuData->arch.active_translation_map = toMap;
@ -390,15 +394,12 @@ arch_thread_context_switch(struct thread *from, struct thread *to)
// get the new page directory
newPageDirectory = (addr_t)toMap->pgdir_phys;
} else {
activeMap = NULL;
newPageDirectory = 0;
// this means no change
}
gX86SwapFPUFunc(from->arch_info.fpu_state, to->arch_info.fpu_state);
i386_context_switch(&from->arch_info, &to->arch_info, newPageDirectory);
if (activeMap != NULL)
activeMap->RemoveReference();
}