This still has thread issues, but a lot of other things need to be
redesigned to correct them.
Particularly, we have a lot of callers that use `mmu_get_page` without
acquiring any locks on the page directory, so in a multithreaded process
one core may be trying to acquire pages while another is unmapping. In
the normal sbrk setup, this shouldn't happen, especially with the locks
in userspace around malloc, and it shouldn't happen with shm as we avoid
dealing with shm pages in the unmap right now, but from the raw API we
provide it's possible for a crafted program to run into it.
The whole memory management API really needs a redesign, much of what we
expose comes from toaru32, and still leaks details about page size into
other code that shouldn't care.
00075494e6