#
2555f335 |
|
14-May-2020 |
Michael Lotz <mmlr@mlotz.ch> |
Cleanup: Various comment and whitespace fixes. Change-Id: I37c3e3346813efc595df651421b7e8ff4fbf3339 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2845 Reviewed-by: waddlesplash <waddlesplash@gmail.com>
|
#
4986a9a3 |
|
24-May-2020 |
Michael Lotz <mmlr@mlotz.ch> |
Revert "kernel: Remove the B_KERNEL_AREA protection flag." This reverts parts of hrev52546 that removed the B_KERNEL_AREA protection flag and replaced it with an address space comparison. Checking for areas in the kernel address space inside a user address space does not work, as areas can only ever belong to one address space. This rendered these checks ineffective and allowed to unmap, delete or resize kernel managed areas from their respective userland teams. That protection was meant to be applied to the team user data area which was introduced to reduce the kernel to userland overhead by directly sharing some data between the two. It was intended to be set up in such a manner that this is safe on the kernel side and the B_KERNEL_AREA flag was introduced specifically for this purpose. Incidentally the actual application of the B_KERNEL_AREA flag on the team user data area was apparently forgotten in the original commit. The absence of that protection allowed applications to induce KDLs by modifying the user area and generating a signal for example. This change restores the B_KERNEL_AREA flag and also applies it to the team user data area. Change-Id: I993bb1cf7c6ae10085100db7df7cc23fe66f4edd Reviewed-on: https://review.haiku-os.org/c/haiku/+/2836 Reviewed-by: waddlesplash <waddlesplash@gmail.com>
|
#
dda8e77b |
|
29-Feb-2020 |
Augustin Cavalier <waddlesplash@gmail.com> |
headers: Move B_KERNEL_{EXECUTE,STACK}_AREA into KernelExport.h. There is no good reason to put them in a private header. No functional change (but drivers now have access to these constants.) Change-Id: I7ac00a120ab44fbc110bc858dfd87d69d0061135 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2294 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> Reviewed-by: John Scipione <jscipione@gmail.com>
|
#
8a0c9d52 |
|
10-Aug-2019 |
Augustin Cavalier <waddlesplash@gmail.com> |
OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA. It now lives in OS.h. The idea is that this will now be accessible to userland applications, so userland memory is protected from access by other processes, just as kernel memory is. No functional change (the constants are still the same, though I've changed some to use shifts to make clear which bits are allocated are which are unused.)
|
#
9cc0f06a |
|
17-Nov-2018 |
Augustin Cavalier <waddlesplash@gmail.com> |
kernel: Remove the B_KERNEL_AREA protection flag. It is now no longer used.
|
#
5d0a1da8 |
|
14-May-2013 |
Pawel Dziepak <pdziepak@quarnos.org> |
libroot: make all areas executable for old binaries * If at least one image is either B_HAIKU_ABI_GCC_2_ANCIENT or B_HAIKU_ABI_GCC_2_BEOS almost all areas are marked as executable. * B_EXECUTE_AREA and B_STACK_AREA are made public. The former is enforced since the introduction of DEP and apps need it to correctly set area protection. The latter is currently needed only to recognize stack areas and fix their protection in compatibility mode, but may also be useful if an app wants to use sigaltstack from POSIX API.
|
#
9fb2d737 |
|
23-Jun-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Replaced B_32_BIT_MEMORY by B_32_BIT_FULL_LOCK and B_32_BIT_CONTIGUOUS, so the constraint can be expressed more precisely. ATM B_32_BIT_FULL_LOCK is implemented as B_32_BIT_CONTIGUOUS when B_HAIKU_PHYSICAL_BITS > 32, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37226 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
90788614 |
|
01-May-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Changed some parameters of VM syscalls from int to uint32, mostly for sake of consistency. * Moved the B_OVERCOMMITTING_AREA flag from B_KERNEL_AREA_FLAGS to B_USER_AREA_FLAGS, since we really allow it to be passed from userland. * Most VM syscalls check the provided protection against B_USER_AREA_FLAGS instead of B_USER_PROTECTION, now. This way they allow for B_OVERCOMMITTING_AREA as well. * _user_map_file(), _user_set_memory_protection(): Check the protection like the other syscalls do and use fix_protection() instead of doing that manually. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36572 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
47c40a10 |
|
19-Oct-2008 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Prefixed memset_physical() and memcpy_to_physical() with "vm_", added vm_memcpy_from_physical() and vm_memcpy_physical_page(), and added respective functions to the vm_translation_map operations. The architecture specific implementation can now decide how to implement them most efficiently. Added generic implementations that can be used, though. * Changed vm_{get,put}_physical_page(). The former no longer accepts flags (the only flag PHYSICAL_PAGE_DONT_WAIT wasn't needed anymore). Instead it returns an implementation-specific handle that has to be passed to the latter. Added vm_{get,put}_physical_page_current_cpu() and *_debug() variants, that work only for the current CPU, respectively when in the kernel debugger. Also adjusted the vm_translation_map operations accordingly. * Made consequent use of the physical memory operations in the source tree. * Also adjusted the m68k and ppc implementations with respect to the vm_translation_map operation changes, but they are probably broken, nevertheless. * For x86 the generic physical page mapper isn't used anymore. It is suboptimal in any case. For systems with small memory it is too much overhead, since one can just map the complete physical memory (that's not done yet, though). For systems with large memory it counteracts the VM strategy to reuse the least recently used pages. Since those pages will most likely not be mapped by the page mapper anymore, it will keep remapping chunks. This was also the reason why building Haiku in Haiku was significantly faster with only 256 MB RAM (since that much could be kept mapped all the time). Now we're using a different strategy: We have small pools of virtual page slots per CPU that are used for the physical page operations (memset_physical(), memcpy_*_physical()) with CPU-pinned thread. Furthermore we have four slots per translation map, which are used to map page tables. These changes speed up the Haiku image build in Haiku significantly. On my Core2 Duo 2.2 GHz 2 GB machine about 40% to 20 min 40 s (KDEBUG disabled, block cache debug disabled). Still more than factor 3 slower than FreeBSD and Linux, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28244 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
1b6eff28 |
|
11-Oct-2008 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Replaced the vm_get_physical_page() "flags" PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag PHYSICAL_PAGE_DONT_WAIT. * Pass the flags through to the chunk mapper callback. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
6b202f4e |
|
13-May-2008 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Introduced new header directory headers/private/system which is supposed to contain headers shared by kernel and userland (mainly libroot). * Moved quite a few private kernel headers to the new location. Split several kernel headers into a shared part and one that is still kernel private. Adjusted all affected Jamfiles and source in the standard x86 build accordingly. The build for other architectures and for test code may be broken. * Quite a bit of userland code still includes private kernel headers. Mostly those are <util/*> headers. The ones that aren't strictly kernel-only should be moved to some other place (maybe headers/private/shared/util). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25486 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
5d0a1da8bf914d4a26bba97ba40cbb36bf99ce52 |
|
14-May-2013 |
Pawel Dziepak <pdziepak@quarnos.org> |
libroot: make all areas executable for old binaries * If at least one image is either B_HAIKU_ABI_GCC_2_ANCIENT or B_HAIKU_ABI_GCC_2_BEOS almost all areas are marked as executable. * B_EXECUTE_AREA and B_STACK_AREA are made public. The former is enforced since the introduction of DEP and apps need it to correctly set area protection. The latter is currently needed only to recognize stack areas and fix their protection in compatibility mode, but may also be useful if an app wants to use sigaltstack from POSIX API.
|
#
9fb2d73772382ea2ccfb62e912f9bfb9c39ac26d |
|
23-Jun-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Replaced B_32_BIT_MEMORY by B_32_BIT_FULL_LOCK and B_32_BIT_CONTIGUOUS, so the constraint can be expressed more precisely. ATM B_32_BIT_FULL_LOCK is implemented as B_32_BIT_CONTIGUOUS when B_HAIKU_PHYSICAL_BITS > 32, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37226 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
907886143fe5656bb1ae0e616a9286b0ca8538c6 |
|
01-May-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Changed some parameters of VM syscalls from int to uint32, mostly for sake of consistency. * Moved the B_OVERCOMMITTING_AREA flag from B_KERNEL_AREA_FLAGS to B_USER_AREA_FLAGS, since we really allow it to be passed from userland. * Most VM syscalls check the provided protection against B_USER_AREA_FLAGS instead of B_USER_PROTECTION, now. This way they allow for B_OVERCOMMITTING_AREA as well. * _user_map_file(), _user_set_memory_protection(): Check the protection like the other syscalls do and use fix_protection() instead of doing that manually. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36572 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
47c40a10a10dc615e078754503f2c19b9f98c38d |
|
19-Oct-2008 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Prefixed memset_physical() and memcpy_to_physical() with "vm_", added vm_memcpy_from_physical() and vm_memcpy_physical_page(), and added respective functions to the vm_translation_map operations. The architecture specific implementation can now decide how to implement them most efficiently. Added generic implementations that can be used, though. * Changed vm_{get,put}_physical_page(). The former no longer accepts flags (the only flag PHYSICAL_PAGE_DONT_WAIT wasn't needed anymore). Instead it returns an implementation-specific handle that has to be passed to the latter. Added vm_{get,put}_physical_page_current_cpu() and *_debug() variants, that work only for the current CPU, respectively when in the kernel debugger. Also adjusted the vm_translation_map operations accordingly. * Made consequent use of the physical memory operations in the source tree. * Also adjusted the m68k and ppc implementations with respect to the vm_translation_map operation changes, but they are probably broken, nevertheless. * For x86 the generic physical page mapper isn't used anymore. It is suboptimal in any case. For systems with small memory it is too much overhead, since one can just map the complete physical memory (that's not done yet, though). For systems with large memory it counteracts the VM strategy to reuse the least recently used pages. Since those pages will most likely not be mapped by the page mapper anymore, it will keep remapping chunks. This was also the reason why building Haiku in Haiku was significantly faster with only 256 MB RAM (since that much could be kept mapped all the time). Now we're using a different strategy: We have small pools of virtual page slots per CPU that are used for the physical page operations (memset_physical(), memcpy_*_physical()) with CPU-pinned thread. Furthermore we have four slots per translation map, which are used to map page tables. These changes speed up the Haiku image build in Haiku significantly. On my Core2 Duo 2.2 GHz 2 GB machine about 40% to 20 min 40 s (KDEBUG disabled, block cache debug disabled). Still more than factor 3 slower than FreeBSD and Linux, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28244 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
1b6eff280f4afcf4d7c9dc9ccdc3a65f4e6ca0fd |
|
11-Oct-2008 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Replaced the vm_get_physical_page() "flags" PHYSICAL_PAGE_{NO,CAN}_WAIT into an actual flag PHYSICAL_PAGE_DONT_WAIT. * Pass the flags through to the chunk mapper callback. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27979 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
6b202f4e3da73d4c131355fcd82b792d153f84f6 |
|
13-May-2008 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Introduced new header directory headers/private/system which is supposed to contain headers shared by kernel and userland (mainly libroot). * Moved quite a few private kernel headers to the new location. Split several kernel headers into a shared part and one that is still kernel private. Adjusted all affected Jamfiles and source in the standard x86 build accordingly. The build for other architectures and for test code may be broken. * Quite a bit of userland code still includes private kernel headers. Mostly those are <util/*> headers. The ones that aren't strictly kernel-only should be moved to some other place (maybe headers/private/shared/util). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25486 a95241bf-73f2-0310-859d-f6bbb57e9c96
|