c25f6f53b5
The old implementation used the real lock_memory(). This is problematic and does not work for a large number of reasons: 1) Various parts of the kernel assume memory is locked only very temporarily, and will often wait on locked memory to become unlocked. The transient nature of locks is further demonstrated by the fact that lock_memory acquires references to structures, like the address space, which are only released by unlock_memory 2) The VM has a hard assumption that all lock_memory calls will be exactly balanced, and maintains internal "WiredRange" structures on areas, etc. corresponding to the original lock_memory calls. Maintaining separate data structures as this code did is a recipe for even more problems when the structures are manipulated separately, leading to confusing or incorrect behavior on unlocks. 3) Areas with locked memory cannot be deleted, nor can the pages which are locked be removed from the areas/caches. This of course is most notable when destroying teams which locked memory, but the problem also occurs when just using delete_area, resize_area, mmap/munmap, etc. Because of (2) and especially (3), adding support for mlock()-like semantics to the existing memory locking system is just not a good option. A further reason is that our lock_memory is much stricter than mlock(), which only demands the pages in question must remain resident in RAM and cannot be swapped out (or, it seems, otherwise written back to disk.) Thus, this commit completely removes the old implementation (which was seriously broken and did not actually automatically unlock memory on team exit or area destruction at all, etc.) and instead adds a new feature to VMAnonymousCache to block certain pages from being written out. The syscall then just invokes this to do its work. Fixes #17674. Related to #13651. Change-Id: Id2745c51796bcf9a74ba5325fe686a95623cd521 Reviewed-on: https://review.haiku-os.org/c/haiku/+/5147 Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku
Homepage | Mailing Lists | IRC Channels | Issue Tracker | API docs
Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful.
Goals
- Sensible defaults with minimal configuration required.
- Clean, clear, concise code.
- Unified desktop environment.
Trying Haiku
Haiku provides pre-built nightly images and release images. Haiku is compatible with a large variety of hardware, but in case you don't want to "take the plunge" and install Haiku on bare metal, you can install it on a virtual machine (VM) instead. If you've never used a VM before, you can follow one of the "Emulating Haiku" guides.
Compiling Haiku
See ReadMe.Compiling.
Contributing
Haiku is a meritocratic open source project with a large variety of tasks. Even if you can't write code, you can still help! Haiku needs designers, (technical) writers, translators, testers... Get involved and help out!
Contributing code
If you're submitting a patch to us, please make sure you're following the patch submitting guidelines.
If you're having trouble finding something in the source tree, you can use one of our web-based source code browsers:
- https://xref.landonf.org/ (OpenGrok, provided by Landon Fuller)
- https://git.haiku-os.org/ (git, provided by Haiku, Inc.)
Contributing documentation
The main piece of documentation that still needs work are the API docs (found
in the tree at docs/user). Just find an undocumented class, write
documentation for it, and submit a patch.
Contributing translations
See wiki:i18n.
Contributing software ports
See HaikuPorts.
Contributing to our infrastructure
See Infrastructure.