kernel/vm: Do not try to reserve more memory than the system has.

All that happens is we wait unnecessarily, and cause the low_resource
monitor to run a lot, so we should skip doing that here altogether.

Encountered while running Falkon (Chromium): some part of Chromium
repeatedly tries to allocate 10+GB, more than my system has, which caused
the system to "stutter" due to low-resource-monitor runs locking
various kernel subsystems. This prevents that problem.

kernel/vm: Avoid committing memory in vm_map_file for PRIVATE_MAP without PROT_WRITE.

Instead, rely on commitment being done later, when the
protections are changed. set_area_protection() already
did just that, but set_memory_protection did not, so
it is implemented here.

Fixes #18733.

Change-Id: Ia58aee93faf1296fce69d723b12d0fa0a8440706
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7339
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel/vm: Perform area ownership check before protection check.

This way we do not "leak" area protection status (not really a
significant concern at the moment, but might as well while I
was looking at this.)

kernel/vm: Allow B_CLONEABLE_AREA flag to be added through set_area_protection.

kernel: Implement realloc_etc and make use of it.

kernel/vm: check if page is in area

Checks if a `vm_page` is part of a `VMArea` before doing work with
it, as pages in a `VMCache` that an area is a part of might not
belong to that area.

This fixes a bug for copy-on-write areas when an application is
`fork`ing.

Change-Id: Ic5683c67865b41bf3708bb7ea4104502ddf31a19
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6496
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>

kernel/vm: handle page protections in cut_area

- Resize the `page_protections` array in `cut_area` and also shift
the bits if necessary.
- Set the correct protection array as well as the real page
protections for the second area produced by `cut_area`.

Change-Id: I62293480487e869420ebe5a3bc729cec2a14c687
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6395
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>

kernel/vm: unlock cache before unmapping addresses

Unlock the current cache in `map_backing_store` before
`unmap_address_range` is called, since `unmap_address_range` may
call `delete_area` which would then also attempt to lock the same
cache if that cache has already been mapped to an area in the
conflicting address range.

Fixes #18422.

Change-Id: I6fc5301c43d11bb6df489a2e6d6bdcd6cd80d2b7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6392
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>

Revert "kernel/vm: handle page protections in cut_area"

This reverts commit de07bc3fa58600e923d75cb732c60dacf160c098.

That's what I get for fixing bugs on test branches.

kernel/vm: handle page protections in cut_area

- Resize the `page_protections` array in `cut_area` and also shift
the bits if necessary.
- Set the correct protection array as well as the real page
protections for the second area produced by `cut_area`.

Change-Id: I62293480487e828970ebe5a3bc729cec2a14c687

kernel/vm: Make cut_area respect overcommitting flag

`cut_area` now checks the protection of the target area for
the `B_OVERCOMMITTING_AREA` flag and sets it on any cache it
creates. This allows operations that split large overcommitting
areas to succeed.

Change-Id: I8dee27d22df29741cc61af2575c9e6626da25949
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6391
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel/vm: Allow more maximum protection for mmap'ed areas

Always allow a memory region mapped by `map_file` to change its
protection to any user protection flags other than `B_WRITE_AREA`.
This flag should only be settable when the file is opened with
write access.

Change-Id: Icc00c08fc033b3bd6b6ceb2833bf566c72914007
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6389
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: John Scipione <jscipione@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel/vm: Fix area_for with PROT_NONE address

Do not assume "no user protection" means "kernel area".

This allows calls to `area_for` for addresses with protection 0
to work properly.

Change-Id: I54cbcc154d10b63359a2e1233f0c0f45d0d8e21e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6388
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

vm: Replace the VMAreas OpenHashTable with an AVLTree.

Since we used a hash table with a fixed size (1024), collisions were
obviously inevitable, meaning that while insertions would always be
fast, lookups and deletions would take linear time to search the
linked-list for the area in question. For recently-created areas,
this would be fast; for less-recently-created areas, it would get
slower and slower and slower.

A particularly pathological case was the "mmap/24-1" test from the
Open POSIX Testsuite, which creates millions of areas until it hits
ENOMEM; it then simply exits, at which point it would run for minutes
and minutes in the kernel team deletion routines; how long I don't know,
as I rebooted before it finished.

This change fixes that problem, among others, at the cost of increased
area creation time, by using an AVL tree instead of a hash. For comparison,
mmap'ing 2 million areas with the "24-1" test before this change took
around 0m2.706s of real time, while afterwards it takes about 0m3.118s,
or around a 15% increase (1.152x).

On the other hand, the total test runtime for 2 million areas went from
around 2m11.050s to 0m4.035s, or around a 97% decrease (0.031x); in other
words, with this new code, it is *32 times faster.*

Area insertion will no longer be O(1), however, so the time increase
may go up with the number of areas present on the system; but if it's
only around 3 seconds to create 2 million areas, or about 1.56 us per area,
vs. 1.35 us before, I don't think that's worth worrying about.

My nonscientific "compile HaikuDepot with 2 cores in VM" benchmark
seems to be within the realm of "noise", anyway, with most results
both before and after this change coming in around 47s real time.

Change-Id: I230e17de4f80304d082152af83db8bd5abe7b831

kernel/vm: Prohibit offset from being < 0 in mmap.

POSIX seems to be silent about whether this is permitted,
but at least FreeBSD explicitly does not allow it.

Fixes #16936.

Change-Id: If6b23410ae88245e706df77d276234f4775654f9

kernel/vm: also honor page protections on copy-on-write

this fixes #17895

Change-Id: Ide6cb044cf96213b4bae7eb62235f988b73c0fb1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5601
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel/vm: _user_set_memory_protection() should only check the user protection

as it extends the provided protection with the kernel protection.
fix hrev55016

Change-Id: I9fa9349c15b4ef896a9dadd1b1b7a4165cc03b39
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5531
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel: Move validate_user_memory_range to kernel.h and rename it.

It has more general use than just in the VM code; basically anything
which receives buffers from userland should be invoking this if it
does anything besides user_memcpy (which alreay does it.)

kernel/vm: Remove default kernel read/write flags

`fix_protection` will not apply `B_KERNEL_READ_AREA` and
`B_KERNEL_WRITE_AREA` by default.

Kernel drivers that directly call `create_area` or `create_area_etc`
and do not pass any protection flags have been updated to
apply `B_KERNEL_READ_AREA | B_KERNEL_WRITE_AREA` instead.

Bug: #17751
Change-Id: I43e7ee6b5396e0309cdcff750e28262942c6d01c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5330
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel/vm: Completely replace mlock() implementation.

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>

kernel/vm: Add user address checks to mlock routines.

Also adjust general checks at the beginning. Patterned after
_user_set_memory_protection.

kernel/vm: Use ObjectDelter and slight cleanup to the mlock() routines.

kernel/vm: Let _user_set_memory_protection change area->protection if possible.

If mprotect() is being run over an entire area, and the area does
not have per-page protections, then we can just invoke set_area_protection
instead of allocating a protections array.

This is a major efficiency increase, as every page fault would otherwise
have to use the protections array if it was allocated.

Testing with QtWebEngine shows this new path being hit relatively often
(multiple hundred times in loading a single webpage).

Change-Id: I60258d56f681060861602922f3fbdbce2fd380d6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5097
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>

kernel/vm: Cleanups and minor fixes to get_area_page_protection.

* We should not assume all non-kernel areas have KERNEL_READ_AREA
permission, but follow the other permission flags directly.
This way the kernel will be blocked from accessing guard pages, too.

* Compute kernelProtection only once, and either return it directly
or return it OR'd with the user protections.

Change-Id: Id6daa1cd15eb3102e23f95c08672ad97344e0722
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5096
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>

kernel/vm: Use get_area_page_protection in all cases of _user_get_memory_properties.

It already checks for area->page_protections == NULL and returns
area->protection appropriately if so, we do not need to test specifically
for that here.

No functional change intended.

kernel/vm: De-wrap line for clarity.

No functional change. Now it looks the same as the surrounding checks.

kernel/vm: Do not assume "no user protection" means "kernel area".

It's entirely possible that we have a user area with a page that
has protections of 0 (e.g. a guard page). In that case we should
print the standard read/write fault message instead of "kernel"
fault messages.

This should not be a major behavioral change, only the syslog
and tracing entries should be affected; such memory accesses
should be caught by the read/write permissions checks immediately
following.

kernel/vm: Check the area's cache_type, not the cache's, in cut_area.

It seems this is the type of the innermost source cache, not the
topmost cache (which well may be "RAM" if this is an anonymous cache
on top of a Vnode cache.)

Originally VMArea::cache_type was introduced 15 years ago
(commit 0c12332715ae3cd6dedad4270d52ccf29d2cdcbf, 2007)
merely to mirror the underlying cache's type. Somewhere along the way,
it acquired different values. As the VM has changed a lot since then,
perhaps its overall purpose should be re-evaluated?

Fixes #17556.

kernel/vm: Notify the low_resource manager on low_resource address space.

We cannot wait here, but now that the low_resource manager actually
does something with the information it is provided, we can invoke it.

riscv64/smp: Implement multi-processor support

* Working under qemu smp 1,2+
* Working on SiFive Unmatched
* x86_64 efi not broken by smp_boot_other_cpus change

Change-Id: I32ebc17913e46ed082be9ade8f56448bbf12f16e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4705
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>

kernel/vm: Allow locking kernel space if allocating page_protections for userspace.

Some applications may request per-page protections for an especially
large area (e.g. multiple GB), which leads to allocating a rather
large page protections area (e.g. 512KB), which we cannot allocate
without locking the kernel space to get new slabs.

We only need to avoid locking the kernel space if the area in question
is in the kernel space, as in that case, kernel space will already be
read-locked by the current thread.

Fixes #16898.

Change-Id: If52413a594da66edfc2821811d959085a2c3c78e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4436
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel: Break thread-related AutoLockers into a separate header.

Including thread.h brings a massive array of things with it from
the kernel thread arch headers, team and thread definitions,
hash tables, linked lists, Referenceable, etc. that the vast majority
of AutoLock.h consumers neither want nor need.

So, put these in a separate header, and adjust all consumers of these
lockers to include the new file.

This change exposes the fact that a lot of files were inadvertently
making use of headers included indirectly through thread.h. Those
will be fixed in the next commit.

vm: fix off by one errors

Various functions would return an error if trying to use them on the
last page of userspace, as they tested the permissions for the first
byte out of the requested range. Also, the code was duplicated in
several places

- Rename validate_user_range to validate_memory_range. The "user" in the
name was to mean that the range is provided by the user calling the
syscall, but it is a bit confusing, as the function accepts any range
that is either in kernel or in user memory.
- Add a new function validate_user_memory_range that only accepts
userspace memory, and use this one where appropriate.

Change-Id: I135f8d584340f0ba4ae7e4b8cb6f8600fbf3ef2d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4212
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>

kernel/vm: restrict permission changes on shared file-mapped areas

a protection_max attribute is added in VMArea.
a read-only opened file already can't be mapped shared read-write at the moment,
but can later be changed to read-write with mprotect() or set_area_protection().
When creating the VMArea, the actual maximum protection is stored in the area,
so that it can be checked when needed.
this fixes a VM TODO.

Change-Id: I33b144c192034eeb059f1dede5dbef5af947280d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3804
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

use common AutoDeleter types

Change-Id: I115e14b76f3ff049c5f7d9471efd3619a0038fcf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3483
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>

fix build after CObjectDeleter interface change

Change-Id: I76e217abcd13c22c4d68170e07333cdde4d7a891
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3461
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

kernel: Allow usage of magic team constants in create_area_etc.

All other functions that support these handle them specifically,
so vm_create_anonymous_area must do so as well.

Change-Id: I7233770926b718936baeff10ef73668ac15c5201
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3477
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

implement mlock(), munlock()

Change-Id: I2f04b8986d2ed32bb4d30d238d668e21a1505778
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1991
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

kernel/vm: Dump page protections array address in area command.

Had to abbreviate the trailing 's' to make it fit the alignment...

Change-Id: Iae88c4cd92c3f54bf3ea3433ea3dafe5df90a8e8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3168
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel/vm: Avoid page protection overflows for very large areas.

For areas >= 32TiB the page protection array size would overflow.

Change-Id: Ic95d9a6e35bbedb165c2bbd382f6c47edde07ac2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3167
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel/vm: Make vm_copy_area take page protections into account.

When copying an area with vm_copy_area only the new protection would be
applied and any possibly existing page protections on the source area
were ignored.

For areas with stricter area protection than page protection, this lead
to faults when accessing the copy. In the opposite case it lead to too
relaxed protection. The currently only user of vm_copy_area is
fork_team which goes through all areas of the parent and copies them to
the new team. Hence page protections were ignored on all forked teams.

Remove the protection argument and instead always carry over the source
area protection and duplicate the page protections when present.

Also make sure to take the page protections into account for deciding
whether or not the copy is writable and therefore needs to have copy on
write semantics.

Change-Id: I52f295f2aaa66e31b4900b754343b3be9a19ba30
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3166
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

libroot/kernel: Implement MADV_FREE madvise() extension.

It allows an application to signal that it no longer needs the data in
the given address range and the underlying pages can be discarded and
reused elsewhere. This is finer grained than working with full areas
or mappings at a time and enables unmapping sections of partially used
mappings without giving up its address space.

Compared with punching holes into a mapping by "mapping over" with
PROT_NONE and MAP_NORESERVE, this has the obvious advantage of not
producing a lot of unused extra areas and saves the corresponding
resources. It is also a lot "lighter" of an operation than cutting
existing areas.

This introduces madvise() alongside the existing posix_madvise() to
allow for OS specific extensions. The constants for both functions are
aliased, the POSIX_MADV_* being a subset of the MADV_* ones without the
non-POSIX extensions. Internally posix_madvise() simply calls madvise().

MADV_FREE is commonly supported in other OSes with various subtle
semantic differences as to when pages are actually freed/cleared and how
or whether the pages are counted against the memory use of a process.
In the variant implemented here, pages are always immediately discarded
and memory counting is not altered. This behaviour should be considered
an implementation detail and may be altered later. The actual unmap and
discard could for example be delayed until pages are needed elsewhere to
reduce overhead in case of repeated discarding and remapping.

Note that MADV_FREE doesn't really align with the rest of the madvise()
API as it works like a command (i.e. discard these pages) and does not
add an attribute to the pages in the given range (i.e. mark these pages
for quick access from now on). As such, an MADV_FREE does not need to be
undone by setting a different advice later on, unlike how the other
flags work. This discrepancy may be the reason why it is not part of
POSIX.

Change-Id: Icc093379125a43e465dc4409d8f5ae0f64e107e0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2844
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel/vm: Add discard_address_range that discards pages.

Pages in the given range are unmapped and freed without getting written
back anywhere. It can be used whenever a caller does not care about the
data in the given range anymore and wants to reduce page pressure.

Change-Id: I8bcce68fab278efef710d3714677e1d463504a56
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2843
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel: Whitespace cleanup only.

kernel/vm: Introduce and use VMAddressSpace::AreaRangeIterator.

It iterates over all areas intersecting a given address range and
removes the need for manually skipping uninteresting initial areas. It
uses VMAddressSpace::FindClosestArea() to efficiently find the starting
area.

This speeds up the two iterations in unmap_address_range and one in
wait_if_address_range_is_wired and resolves a TODO in the latter hinting
at such a solution.

Change-Id: Iba1d39942db4e4b27e17706be194496f9d4279ed
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2841
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel/vm: Remove linear search from _get_next_area_info.

This introduces VMAddressSpace::FindClosestArea() that can be used to
find the closest area to a given address in either direction. This is
now trivial and efficient since both kernel and user address spaces use
a binary search tree.

Using FindClosestArea() getting multiple area infos is sped up
dramatically as it removes the need for a linear search from the first
area to the one given in the cookie on each successive invocation.

Change-Id: I227da87d915f6f3d3ef88bfeb6be5d4c97c3baaa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2840
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel/vm: Factor out intersect_area and use it for cut_area.

It combines the intersection check and setting address, size and offset
so that they fall within the area.

Change-Id: Iffd3feca75d4e6389d23b9d70294253b4c3d1f4c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2837
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

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>

kernel/vm: Implement swap adoption for cut_area middle case.

Rename MovePageRange to Adopt and group it with Resize/Rebase as it
covers the third, middle cut case.

Implement VMAnonymousCache::Adopt() to actually adopt swap pages. This
has to recreate swap blocks instead of taking them over from the source
cache as the cut offset or base offset between the caches may not be
swap block aligned. This means that adoption may fail due to memory
shortage in allocating the swap blocks.

For the middle cut case it is therefore now possible to have the adopt
fail in which case the previous cache restore logic is applied. Since
the readoption of the pages from the second cache can fail for the same
reason, there is a slight chance that we can't restore and lose pages.
For now, just panic in such a case and add a TODO to free memory and
retry.

Change-Id: I9a661f00c8f03bbbea2fe6dee90371c68d7951e6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2588
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel/vm: Factor out condition for cache resizing in cut_area.

Change-Id: I2c49b550f72b9778934abbf90a04579caa7b43f2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2587
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel/vm: Inherit the temporariness of source cache on split.

Otherwise pages from it would later be tried to be written back with
nowhere to go in case of temporary caches.

Change-Id: I81e7335408c419a9b2c7bbb31290d551f5508d56
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2586
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel/vm: Use already determined priority in middle cut_area.

Change-Id: I4dd677a0f1378f4fa483502124bea70ad7ba40c0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2585
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

Resize caches in all cases when cutting areas

* Adds VMCache::MovePageRange() and VMCache::Rebase() to facilitate
this.

Applied on top of hrev45098 and rebased with the hrev45564 page_num_t to
off_t change included.

Change-Id: Ie61bf43696783e3376fb4144ddced3781aa092ba
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2581
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel/vm: Revise overflow checking in user_strlcpy.

Change-Id: I6a066e7b2c51ff94d80381fcc940565f777209e7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2376
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

Kernel: remove dead code

area->name is a fixed array inside struct, not pointer, so it should
be never be NULL.

Pointed by clang.

Change-Id: Ic8930450cb8461eef158bc854f214eb47d92ce22
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2391
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>

kernel/vm: Validate user addresses do not cross the kernel/user boundary.

This protects against malicious programs trying to steal/overwrite
kernel memory by overflowing user buffers.

Note that this constitutes a behavioral change to user_strlcpy:
previously, address overflows on the "source" side would either
copy less data, or copy some data and fail anyway. Now, address
overflows on either side will always fail before any data is
copied at all.

Change-Id: I01d8b22672ab3758a9dd87b521af6fedd0487417
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2361
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

kernel: Turn the clone-area-attempt panic into a dprintf.

kernel/vm: Enable area-cloning protection for userland areas, too.

We allow teams to clone areas within themselves, but I'm not sure
exactly what use that has. The kernel can of course clone anything
it wants to, still.

Hopefully this will prove substantially less disruptive than the
reverse change last year, as the preceding commits are likely the
only major consumers of this API, rather than a variety of drivers
that need to be individually tested.

kernel/vm: Set CLONEABLE_AREA before cloning areas for transfer.

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.)

kernel/vm: Do not invoke the low_resource monitor in map_backing_store.

As the comment implies, we don't want to wait here, but low_resource()
waits forever when timeout=0. It doesn't seem to do anything with the
"size" argument at all, so not calling it is just as effective, and so
replace the comment there altogether.

The case where this was most often hit, causing a full system deadlock
in anything relating to memory management, was when the passed "size"
was 0. So now we check for this case explicity at the beginning and
panic() on KDEBUG kernels for it.

Change all references to "__INTEL__" to "__i386__".

They are functionally identical, but the former is a BeOS/Haiku-specfic
macro that we include in the compiler specs, and the latter is defined
by GCC.

vm: fix stack erase when printing 64bit value

Getting 64 bytes of data in a 32 bit variable is a bad idea

Change-Id: I760e1cfb996a9be053dbc50d6610b3e865cde65d
Reviewed-on: https://review.haiku-os.org/c/1096
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel: Don't retry or wait for the low_resource handler.

As axeld pointed out on the mailing list, map_backing_store is called
with the address space write-locked, and so the resources won't be
released until after we return.

Due to the state we are in at this point, unlocking the address space
before making this call would be likely be very dangerous, and so
simply issuing the notification and then returning an error is all
we can safely do here.

kernel: Notify low resource handler & retry when low on kernel address space.

Solves a decade-old TODO. This might help with strange behavior in
low-memory conditions.

vm: Allow W|X before kernel startup ends.

The altcodepatch mechanism needs to overwrite parts of the kernel
image. This can't be done by setting it to RW-only and not RWX,
as we are already running within the kernel when this occurs,
and so instruction fetches can and will occur between the points
of +W and -W.

As gKernelStartup is turned off before the scheduler is started,
this is not much of a lifted restriction, as no modules are loaded,
no secondary threads started, etc.

Fixes #14751.

kernel: Enforce W^X protection for kernel areas.

We already adhere to this in the kernel itself as well as all
in-tree drivers, so we might as well actually enforce it now.

vm: B_EXECUTE_AREA should not imply B_KERNEL_EXECUTE_AREA.

Trying to execute user-mapped areas in kernel space should trigger
a fault with SMEP enabled anyway (and we have not seen any thus far.)

vm: Block userland from modifying any area owned by the kernel.

Previously this protection was possible via the opt-in B_KERNEL_AREA flag,
however, almost nothing used that, so in practice these protections were
rarely enforced.

Userland can still access kernel areas according to the protection flags
(and due to SMAP, these have been refined and reduced as appopriate)
and clone them (according to B_USER_CLONEABLE_AREA flag, which has
been required since August of this year), but they can no longer
resize them (something no in-tree application does on any shared area),
set protections (otherwise they could add B_USER_CLONEABLE_AREA...),
unmap them, or essentially do anything else besides get their
information (and even that we should restrict to uid 0, in the future.)

From my testing, this does not introduce any issues, and no applications
nor drivers should have been relying on the previous behavior (unlike
SMAP or the clone-area changes, which did affect applications.)

kernel/vm: Remove hacky stack dumper from vm_page_fault.

As the TODO said, we now have good userland debugging facilities, so
this isn't needed (and has been if 0'd out for almost a decade now.)
The dprintf on page faults may still be useful under rare circumstances,
but we already have a "TRACE_FAULTS" configuration for this file,
so guard it behind that.

Fixes part of #14360.

kernel: Include the area name and ID in the "attempting to clone" panic message.

Change-Id: Iecc842047929531f8feb7304fbcd1a8f2b28ab2f
Reviewed-on: https://review.haiku-os.org/584
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

vm: Enable B_USER_CLONEABLE_AREA protection.

Spotted while reading through the VM code while thinking about how to
implement vfork().

When axeld disabled this in 2005 (!), Haiku's kernel was still young,
BeOS drivers were still "a thing," and there was no distinction in this
function from being called by the kernel / not by the kernel.

Now, it's 2018, we manage all drivers ourselves, have SMAP enabled by
default when available, and as axeld recently noted on the mailing lists,
"there's not much reason we still use GCC2 for the kernel anyway." So we
probably don't care about any BeOS drivers that may be broken by this
(are there any still around?)

Besides the usual fixes to get this 13-year-old chunk to work again, there
are two functional changes:
1) Allow the kernel to clone whatever it likes into the user's address space.
It seems that this is often done legitimately (e.g. team creation), and
so attempting to distinguish those cases seems more work than it may be
worth right now.

The disadvantage is that drivers without proper checks may be "tricked"
into cloning areas they shouldn't; but I'm guessing if that's the case,
then something else is probably broken and the driver should be fixed.
It seems the reverse case (cloning a userland area into the kernel)
is much more common (in fact, it looks like all 4 of the 4 places
where clone_area is used in kernel-space outside the kernel itself
are doing this.)

2) At KDEBUG_LEVEL 2 and higher, throw a panic when attempting to clone
an area that does not have the protection flag set. This should make
finding any bugs exposed by this change much easier than "hardware doesn't
work" / "black screen on boot" / etc., as well as any potential future
bugs introduced in the process of driver development.

Revert the rest of the COMPAT_MODE changes (back to hrev52003.)

This reverts commit 458e758f3792ef11ca26d6ff7e24600c88326e83.
This reverts commit ce5eb94a82b1b377ef5909e65411e031f54ceb15.
This reverts commit aac8d4c317ca11a9a6e194e2c668e8183ec23dd6.
This reverts commit c70cba914aa79c01bbc2da38085936f589899c8c.
This reverts commit 2ffbe7aaca8668c5a68ac7488459bace7a0700f2
This reverts commit c6e120e2d2f909d95f95839fa99fccf811fdb3c5.

kernel/x86_64: compatibility syscalls for vm.cpp.

* define compat_area_info to be used when applicable in
compatibility mode.
* handle 32-bit types in _user_reserve_address_range(), _user_get_area_info(),
_user_get_next_area_info(), _user_transfer_area(), _user_clone_area(),
_user_create_area(), _user_map_file(), other syscalls are compatible as is.
* _get_next_area_info() doesn't work well with a 32-bit address cookie (address
could be in 64-bit range). Instead use _compat_get_next_area_info() which uses
the area id as cookie, though the areas are not ordered by address any more.

Change-Id: Ic7519ca8824aa2d534b0f03ea75a1bf6ae321535

kernel: Make size argument to create_area_etc() size_t.

It was limited to a uint32 and could for example be overflown by the
slab MemoryManager that uses size_t on a 64 bit system.

This aligns the signature with create_area() that already uses size_t
for the size argument.

Note that the function is currently private, so the impact should be
limited.

kernel: vm: allow mmapping of the last page of the userspace.

Revert "vm: Try harder to allocate early physical pages."

This reverts commit 21e3ac6cf52f91dba8217f15fc33dc1d45dffd40,
which was accidentally applied twice, missed during rebase.

Originally applied in 601b2f7eda4d25b46e7d17e212d22954f28bd0fe.

vm: Try harder to allocate early physical pages.

Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>

kernel: Use anonymous namespaces to avoid type collisions.

The anonymous namespace makes type definitions local to the translation
unit (like static does for objects). For pretty much any type not shared
across multiple files this is what one wants to happen (and might
erroneously expect to happen automatically).

This commit solves some actual collisions that were present:

* The VFS and the rootfs both used an incompatible VnodeHash struct for
their BOpenHashTable.
* XSI semaphores and message queues both used queued_thread, Ipc and
IpcHashTableDefinition.

For release builds these did not cause problems as the types were fully
inlined. Debug builds would crash at boot however because parts of a
BOpenHashTable<VnodeHash> from the rootfs meant to operate on struct
rootfs_vnode would be applied to one from the VFS expecting struct
vnode.

As such collisions are violations of the one definition rule, the code
is at fault and unfortunatley the compiler isn't required to diagnose
such problems across translation units (which isn't actually trivial).
This can lead to subtle and hard to debug problems and it's therefore
best to avoid leaking types into the global namespace whenever possible.

Fix some more type mismatches with std::{min,max}

Remove useless includes of khash.h

* These files were already converted to BOpenHashTable.
* For #9552.

Fix build with guarded heap on x86_64

* Type mismatch.

vm: Try harder to allocate early physical pages.

* On UEFI, pages are allocated top-down; previously,
VM would fail to allocate early pages due to
running into pages allocated at the top and
assume it had run out of pages to map.

Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>

vm_soft_fault(): remove unused wiredRange parameter

vm_soft_fault(): Avoid deadlock waiting for wired ranges

* VMArea::AddWaiterIfWired(): Replace the ignoreRange argument by a
flags argument and introduce (currently only) flag
IGNORE_WRITE_WIRED_RANGES. If specified, ranges wired for writing
are ignored. Ignoring just a single specified range doesn't cut it
in vm_soft_fault(), and there aren't any other users of that feature.
* vm_soft_fault(): When having to unmap a page of a lower cache, this
page cannot be wired for writing. So we can safely ignore all
writed-wired ranges, instead of just our own. We even have to do that
in case there's another thread that concurrently tries to write-wire
the same page, since otherwise we'd deadlock waiting for each other.

vm_soft_fault(): Avoid inconsistent state when seeing wired page

When we encounter a wired page that we'd have to unmap to map our newly
allocated one, we need to get rid of the latter before unlocking
everything and waiting for the wired page. Otherwise we'd leave things
in an inconsistent state (a page from an upper cache shadowing a mapped
page from a lower cache).

vm_soft_fault(): Missing DEBUG_PAGE_ACCESS_END()

... in case we'd need to unmap a page that is wired.

Fixes the immediate issue of #10977. There's a problem remaining (as
discussed in comment 1): If two threads want to wire the same page at
the same time (which led to the assertion being triggered), they will
now deadlock, waiting for each other to remove the pre-registered
VMAreaWiredRange.

kernel: add generic wrapper for accessing user memory

This patch adds user_access() which can be used to gracefully handle
page faults that may happen when accessing user memory. It is used
by arch_cpu_user{memcpy, memset, strlcpy}() to allow using optimized
functions from the standard library.

Currently only x64 uses this, but nothing really is arch specific here.

Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>

kernel/{x86, vm}: Add more error checks in VM initialization

kernel, libroot: Add more memory info in system_info

system_info now contains all information previously available only
through __get_system_info_etc(B_MEMORY_INFO, ...).

dump_mapping_info(): Remove problematic initializer

Fixes gcc 2 build.

KDL "mapping" command: Allow specifying a thread ID

... instead of only a team ID.

KDL "mapping" command: Fix argument check

It wasn't possible to actually specify the second argument (team ID).

Add KDL command "mapping"

* VMTranslationMap:
- Add DebugPrintMappingInfo(): Given a virtual address it is supposed
to print the paging structure information for that address. To be
implemented by derived classes.
- Add DebugGetReverseMappingInfo(): Given a physical addresss it is
supposed to find all virtual addresses mapped to it. To be
implemented by derived classes.
* X86VMTranslationMapPAE: Implement the new methods
DebugPrintMappingInfo() and DebugGetReverseMappingInfo().
* Add KDL command "mapping". It supports both virtual address lookups
and reverse lookups.

unlock_memory_etc(): Fix address space reference leak

unlock_memory_etc() is supposed to release the address space reference
lock_memory_etc() acquired. It didn't do that, though.

vm: lock_memory_etc(): Fix error case

In case something went wrong, call unlock_memory_etc() with the rounded
base address instead of with the original address. If the original
address wasn't page aligned, unlock_memory_etc() would otherwise try to
unlock an additional page.

VM: vm_memset_physical(): Correct length parameter type

elf: restore correct region protection after relocation

vm: force userland to use B_RANDOMIZED_* address specifications

vm: remove B_RANDOMIZED_IMAGE_ADDRESS address specification

This address specification is actually not needed since PIC images can be
located anywhere. Only their size is restriced but that is the compiler and
linker concern. Thanks to Alex Smith for pointing that out.

VM: Fix vm_block_address_range() area protection

B_ALREADY_WIRED, which was erroneously passed for the area protection
parameter to map_backing_store(), has the value 7 which implies user
readable and writable. Hence the address ranges around 0xdeadbeef and
0xcccccccc could actually be read and written from anywhere.

vm: implement B_RANDOMIZED_IMAGE_ADDRESS address specification

On some 64 bit architectures program and library images have to be mapped in
the lower 2 GB of the address space (due to instruction pointer relative
addressing). Address specification B_RANDOMIZED_IMAGE_ADDRESS ensures that
created area satisfies that requirement.

x86: enable data execution prevention

Set execute disable bit for any page that belongs to area with neither
B_EXECUTE_AREA nor B_KERNEL_EXECUTE_AREA set.

In order to take advanage of NX bit in 32 bit protected mode PAE must be
enabled. Thus, from now on it is also enabled when the CPU supports NX bit.

vm_page_fault() takes additional argument which indicates whether page fault
was caused by an illegal instruction fetch.

vm: implement B_RANDOMIZED_ANY_ADDRESS address specification

Randomized equivalent of B_ANY_ADDRESS. When a free space is found (as in
B_ANY_ADDRESS) the base adress is then randomized using _RandomizeAddress
pretty much like it is done in B_RANDOMIZED_BASE_ADDRESS.

vm: implement B_RANDOMIZED_BASE_ADDRESS address specification

B_RAND_BASE_ADDRESS is basically B_BASE_ADDRESS with non-deterministic created
area's base address.

Initial start address is randomized and then the algorithm looks for a large
enough free space in the interval [randomized start, end]. If it fails then
the search is repeated in the interval [original start, randomized start]. In
case it also fails the algorithm falls back to B_ANY_ADDRESS
(B_RANDOMIZED_ANY_ADDRESS when it is implemented) just like B_BASE_ADDRESS does.

Randomization range is limited by kMaxRandomize and kMaxInitialRandomize.

Add support for pthread_attr_get/setguardsize()

* Added the aforementioned functions.
* create_area_etc() now takes a guard size parameter.
* The thread_info::stack_base/end range now refers to the usable range
only.

Fixed possible NULL dereference in vm_page_fault.

This bug was introduced by changing IS_USER_ADDRESS to check against
USER_BASE AND USER_TOP rather than just !IS_KERNEL_ADDRESS. Faults
on addresses outside both the user and kernel address spaces (i.e. the
gap between user and kernel) would result in addressSpace being NULL,
but addressSpace was being used without checking for NULL at one point.

Removed Thread::fault_callback, no longer necessary now that vm86 is gone.

Changed cookie type for get_next_area_info() to ssize_t.

The cookie is used to store the base address of the area that was just
visited. On 64-bit systems, int32 is not sufficient. Therefore, changed
to ssize_t which retains compatibility on x86 while expanding to a
sufficient size on x86_64.

Fixed formatting of output in some debugger commands.

Currently all debugger commands assume 32-bit pointers when formatting their
output. This means that on x86_64 the output is incorrectly formatted. Fixed
this by adding a B_PRINTF_POINTER_WIDTH definition (16 on 64-bit, 8 on
32-bit), and using this to correctly format the output. Not all commands have
been fixed yet, but all VM, slab, VFS, team, thread and image commands should
be correct.

Renamed remaining i386_* functions to x86_* for consistency.

Support ELF64 in the kernel.

This has been done by adding typedefs in elf_common.h to the correct ELF
structures for the architecture, and changing all Elf32_* uses to those
types. I don't know whether image loading works as I cannot test it yet,
there may be some 64-bit safety issues around. However, symbol lookup for
the kernel is working correctly.

Compile APIC and timer code for x86_64, and create an area for the IDT.

Temporary fix for create_preloaded_image_areas. Will be replaced with a typedef later on.

Fixed tracing printf formats in VM code.

Fix ticket #8650.

- Replace arch_cpu_user_strlcpy() and arch_cpu_user_memset() with x86 assembly
versions. These correctly handle the fault handler, which had broken again
on gcc4 for the C versions, causing stack corruption in certain error cases.
The other architectures will still need to have corresponding asm variants
added in order for them to not run into the same issue though.

Changed {,u}int64 to be long rather than long long on x86_64.

Added an ELF64 version of preloaded_image.

* There is now 2 structures, preloaded_elf32_image and preloaded_elf64_image,
which both inherit from preloaded_image.
* For now I've just hardcoded in use of preloaded_elf32_image, but the
bootloader ELF code will shortly be converted to use templates which use
the appropriate structure. The kernel will be changed later when I add
ELF64 support to it.
* All kernel_args data is now compatible between 32-bit and 64-bit kernels.

Changed addr_range to use uint64.

I've tested this change on x86, causing no issues. I've checked over the code
for all other platforms and made the necessary changes and to the best of my
knowledge they should also still work, but I haven't actually built and
tested them. Once I've completed the kernel_args changes the other platforms
will need testing.

More 64-bit compilation/safety fixes.

Fix with enabled tracing.

ASSERT() that there really aren't any wired pages.

Create the right cache type ([non-]swappable) on copy on write.

When forking a team, copy on write areas (and therefore caches) are
created for all the areas in the parent team, but they were always
created as swappable. If the parent team had some B_FULL_LOCK areas,
which aren't swappable, the wrong type of cache would be created which
lead to them not being mergeable later on (causing a panic).

Comments about a possibly cleaner way to figure out the cache type
would be welcome.

Only the to be protected range needs to be non-wired.

When setting memory protection, only ensure/wait for the range that
needs to be protected to not be wired instead of requiering the whole
area to be non-wired. The memory protection is done page wise and
having some parts of the area wired shouldn't preclude other parts to
be protected.

Add heap with guard pages to detect out of bound reads/writes.

This is a very simple heap implementation that allocates memory so that
the end of each allocation always coincides with a page end and is
followed by a guard page which is marked non-present. Out of bounds
access (both read and write) therefore cause a crash (unhandled page
fault).

Note that this allocator is neither speed nor space efficient, indeed it
wastes huge amounts of pages and address space so it is quite easy to
hit limits. It is intended as a pure debug feature.

Introduce debug page wise kernel area protection functions.

This adds a pair of functions vm_prepare_kernel_area_debug_protection()
and vm_set_kernel_area_debug_protection() to set a kernel area up for
page wise protection and to actually protect individual pages
respectively.

It was already possible to read and write protect full areas via area
protection flags and not mapping any actual pages. For areas that
actually have mapped pages this doesn't work however as no fault, at
which the permissions could be checked, is generated on access.

These new functions use the debug helpers of the translation map to mark
individual pages as non-present without unmapping them. This allows them
to be "protected", i.e. causing a fault on read and write access. As they
aren't actually unmapped they can later be marked present again.

Note that these are debug helpers and have quite a few restrictions as
described in the comment above the function and is only useful for some
very specific and constrained use cases.

Don't do the heap size calculation when using the slab as heap.

The initial heap size calculation only applies to the legacy/debug
heap, so it isn't needed when using the slab as kernel heap.

mmlr (distracted) + bonefish:
* Turn VMCache::consumers C list into a DoublyLinkedList.
* Use object caches for the different VMCache types and the VMCacheRefs.
The purpose is to reduce slab area fragmentation.
* Requires the introduction of a pure virtual VMCache::DeleteObject()
method, implemented in the derived classes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43133 a95241bf-73f2-0310-859d-f6bbb57e9c96

bonefish+mmlr:
Move blocking the 0xcccccccc and 0xdeadbeef address ranges from heap to VM init
so that it also works when used in the slab allocator.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43047 a95241bf-73f2-0310-859d-f6bbb57e9c96

Move resizing the page_protections before resizing the cache to avoid a needless
resize operation that has to be undone and may fail when doing so.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42332 a95241bf-73f2-0310-859d-f6bbb57e9c96

When resizing an area that has individual page protections (set via mprotect),
we have to enlarge/shrink the array that holds them and assign a protection
value for the additional pages as necessary. Otherwise we'll access invalid
memory when looking up page protections for enlarged areas and get random
protection values.
Experienced with QEMU that sets page protections via mprotect on heap memory.
When the heap was later enlarged, write access to the additional memory would
result in permission denied errors and crashes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42330 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fix range check. The previous check would produce an off by one error making the
last byte of an unmapped-but-still-there page non-readable (i.e. from B_NO_LOCK
areas), causing such reads to fail in KDL.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42276 a95241bf-73f2-0310-859d-f6bbb57e9c96

Add private get_memory_properties() syscall which allows one to retrieve the
address protection bits as well as the wiring flags for an arbitrary address
in a team's address space. Will be used in the debugger for the purposes
of the memory inspector/editor, in order to determine whether it can in fact
allow editing for the currently inspected address range.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42129 a95241bf-73f2-0310-859d-f6bbb57e9c96

Merged signals-merge branch into trunk with the following changes:
* Reorganized the kernel locking related to threads and teams.
* We now discriminate correctly between process and thread signals. Signal
handlers have been moved to teams. Fixes #5679.
* Implemented real-time signal support, including signal queuing, SA_SIGINFO
support, sigqueue(), sigwaitinfo(), sigtimedwait(), waitid(), and the addition
of the real-time signal range. Closes #1935 and #2695.
* Gave SIGBUS a separate signal number. Fixes #6704.
* Implemented <time.h> clock and timer support, and fixed/completed alarm() and
[set]itimer(). Closes #5682.
* Implemented support for thread cancellation. Closes #5686.
* Moved send_signal() from <signal.h> to <OS.h>. Fixes #7554.
* Lots over smaller more or less related changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42116 a95241bf-73f2-0310-859d-f6bbb57e9c96

CID 10326 - remove superfluous for loop.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40277 a95241bf-73f2-0310-859d-f6bbb57e9c96

Merged the signals branch into trunk, with these changes:
* The team and thread kernel structures have been renamed to Team and Thread
respectively and moved into the new BKernel namespace.
* Several (kernel add-on) sources have been converted from C to C++ since
private kernel headers are included that are no longer C compatible.

Changes after merging:
* Fixed gcc 2 build (warnings mainly in the scary firewire bus manager).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40196 a95241bf-73f2-0310-859d-f6bbb57e9c96

* fix outdated commented dprintf (still useful for local debugging)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38990 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved the vm_page initialization from vm_page.cpp:vm_page_init() to the new
vm_page::Init().
* Made vm_page::wired_count private and added accessor methods.
* Added VMCache::fWiredPagesCount (the number of wired pages the cache
contains) and accessor methods.
* Made more use of vm_page::IsMapped().
* vm_copy_on_write_area(): Added vm_page_reservation* parameter that can be
used to request a special handling for wired pages. If given the wired pages
are replaced by copies and the original pages are moved to the upper cache.
* vm_copy_area():
- We don't need to do any wired ranges handling, if the source area is a
B_SHARED_AREA, since we don't touch the area's mappings in this case.
- We no longer wait for wired ranges of the concerned areas to disappear.
Instead we use the new vm_copy_on_write_area() feature and just let it
copy the wired pages. This fixes #6288, an issue introduced with the use
of user mutexes in libroot: When executing multiple concurrent fork()s all
but the first one would wait on the fork mutex, which (being a user mutex)
would wire a page that the vm_copy_area() of the first fork() would wait
for.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37460 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fixed non-x86 builds. __get_memory_map_haiku() must be the default.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37237 a95241bf-73f2-0310-859d-f6bbb57e9c96

* get_memory_map(): Changed parameters types to fixed-width types.
* Added BeOS compatibility wrappers for get_memory_map(), map_physical_memory(),
and create_area().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37232 a95241bf-73f2-0310-859d-f6bbb57e9c96

vm_create_anonymous_area(): Optimized the B_32_BIT_{FULL_LOCK,CONTIGUOUS}
cases for B_HAIKU_PHYSICAL_BITS > 32 and accessible physical memory < 4 GB.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37231 a95241bf-73f2-0310-859d-f6bbb57e9c96

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

vm_create_anonymous_area():
* Fixed check: If a low *or* high address restriction is given, we need to
force B_CONTIGUOUS wiring.
* Optimization: Contiguous single-page allocation can be allocated as
full-lock, if the no low/high address restrictions are given.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37203 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added area creation "lock" constant B_32_BIT_MEMORY for physically
contiguous memory < 4 GB.
* vm_create_anonymous_area(): Implemented support for B_LOMEM and
B_32_BIT_MEMORY.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37200 a95241bf-73f2-0310-859d-f6bbb57e9c96

Removed never read VMCache::scan_skip.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37195 a95241bf-73f2-0310-859d-f6bbb57e9c96

Mark caches of null areas temporary, so we don't try to write back modified
pages when deleting the area.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37194 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added vm_available_not_needed_memory_debug(), a
vm_available_not_needed_memory() version that can be called from within the
kernel debugger.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37167 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Renamed cache_type_to_string() to vm_cache_type_to_string() and made in
kernel private.
* Moved dumping code from dump_cache() to new VMCache::Dump().
* Override VMCache::Dump() in VMVnodeCache to also print the vnode.
* Removed no longer needed VMCache::GetLock().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37138 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Introduced structures {virtual,physical}_address_restrictions, which specify
restrictions for virtual/physical addresses.
* vm_page_allocate_page_run():
- Fixed conversion of base/limit to array indexes. sPhysicalPageOffset was not
taken into account.
- Takes a physical_address_restrictions instead of base/limit and also
supports alignment and boundary restrictions, now.
* map_backing_store(), VM[User,Kernel]AddressSpace::InsertArea()/
ReserveAddressRange() take a virtual_address_restrictions parameter, now. They
also support an alignment independent from the range size.
* create_area_etc(), vm_create_anonymous_area(): Take
{virtual,physical}_address_restrictions parameters, now.
* Removed no longer needed B_PHYSICAL_BASE_ADDRESS.
* DMAResources:
- Fixed potential overflows of uint32 when initializing from device node
attributes.
- Fixed bounce buffer creation TODOs: By using create_area_etc() with the
new restrictions parameters we can directly support physical high address,
boundary, and alignment.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37131 a95241bf-73f2-0310-859d-f6bbb57e9c96

vm_page_allocate_page_run(): Added parameter "limit", specifying the upper
physical address limit for the page run to allocate.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37086 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed allocate_early_physical_page() to vm_allocate_early_physical_page()
and made it public.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37072 a95241bf-73f2-0310-859d-f6bbb57e9c96

* vm_allocate_early(): Replace "bool blockAlign" parameter by a more flexible
"addr_t aligmnent".
* X86PagingMethod32Bit::PhysicalPageSlotPool::InitInitial(),
generic_vm_physical_page_mapper_init(): Use vm_allocate_early()'s alignment
feature instead of aligning by hand.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37070 a95241bf-73f2-0310-859d-f6bbb57e9c96

Debug output of map_backing_store(), vm_map_physical_memory[_vecs](): Print
the potential input parameter (virtual address) rather than its address. As
suggested by Andreas Faerber in #6141.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37029 a95241bf-73f2-0310-859d-f6bbb57e9c96

Removed no-op VMTranslationMap::InitPostSem() and
VMAddressSpace::InitPostSem().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37025 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Andreas Faerber:
vm_free_unused_boot_loader_range(): Don't free any memory beyond the given
range.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37010 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fixed more address types related issues. Mostly printf() or comparison
warnings, but also some oversights from earlier changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37000 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Introduced type generic_io_vec, which is similar to iovec, but uses types
that are wide enough for both virtual and physical addresses.
* DMABuffer, IORequest, IOScheduler,... and code using them: Use
generic_io_vec and generic_{addr,size}_t where necessary.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36997 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Changed physical_entry::{address,size} to phys_{addr,size}_t and changed
map_physical_memory()'s physicalAddress parameter type from void* to
phys_addr_t. This breaks source compatibility, but -- as long as
phys_{addr,size}_t remain 32 bit wide -- keeps binary compatibility with
BeOS.
* Adjusted all code using the affected interfaces (Oh what fun!). Added a few
TODOs in places where the wrong types (e.g. void* for physical addresses
are used). Looks like quite a few drivers aren't 64 bit safe and others
will break with PAE.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36960 a95241bf-73f2-0310-859d-f6bbb57e9c96

* First run through the kernel's private parts to use phys_{addr,size}_t
where appropriate.
* Typedef'ed page_num_t to phys_addr_t and used it in more places in
vm_page.{h,cpp}.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36937 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added a heap_init_post_area() which is called right after areas can be
created, and moved the heap's grow and VIP heap initialization to it. Should
fix #5956.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36855 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Introduced new area creation flag CREATE_AREA_DONT_COMMIT_MEMORY.
map_backing_store() doesn't commit memory when this flag is given.
* Used the new flag vm_copy_area(): We no longer commit memory for read-only
areas. This prevents read-only mapped files from suddenly requiring memory
after fork(). Might improve the situation on machines with very little RAM
a bit.
We should probably mark writable copies over-committing, since the usual
case is fork() + exec() where the child normally doesn't need more than a
few pages until calling exec(). That would significantly reduce the memory
requirement for jamming the Haiku tree.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36651 a95241bf-73f2-0310-859d-f6bbb57e9c96

Allocate memory for the DEBUG_CACHE_LIST debug feature only when there's
plenty available.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36634 a95241bf-73f2-0310-859d-f6bbb57e9c96

* During early kernel startup, we must not create areas without the
CREATE_AREA_DONT_WAIT flag; waiting at this point is not allowed.
* I hope I found all occurences, but there might be some areas left (note,
only those that don't use B_ALREADY_WIRED are problematic).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36624 a95241bf-73f2-0310-859d-f6bbb57e9c96

vm_map_physical_memory(): When alreadyWired we have to explicitly set the
memory type for the mapped pages.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36590 a95241bf-73f2-0310-859d-f6bbb57e9c96

* VMTranslationMap::Map()/Protect(): Added "memoryType" parameter. Not
implemented for any architecture yet.
* vm_set_area_memory_type(): Call VMTranslationMap::ProtectArea() to change the
memory type for the already mapped pages.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36574 a95241bf-73f2-0310-859d-f6bbb57e9c96

* VMArea: Made memory_type private and added setter and getter methods.
* Don't set the VMArea's memory type in arch_vm_set_memory_type(), but let the
callers do that.
* vm_set_area_memory_type(): Does nothing, if the memory type doesn't change.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36573 a95241bf-73f2-0310-859d-f6bbb57e9c96

* 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

map_backing_store(): Also consider the B_OVERCOMMITTING_AREA for private
maps. The new cache will be created in over-committing mode.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36550 a95241bf-73f2-0310-859d-f6bbb57e9c96

vm_create_anonymous_area(): Allocate the page run for B_CONTIGUOUS areas
before locking the address space. That gives us a bit more flexibility in
vm_page_allocate_page_run().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36486 a95241bf-73f2-0310-859d-f6bbb57e9c96

get_memory_map_etc(): Setting the return value to B_BUFFER_OVERFLOW in the
loop causes the function to return before setting the _numEntries. The
overflow case is checked at the end of the function anyway, so we can just
break out.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36425 a95241bf-73f2-0310-859d-f6bbb57e9c96

cut_area(): We should only resize RAM caches.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36372 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Fixed incorrect indentation.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36258 a95241bf-73f2-0310-859d-f6bbb57e9c96

wait_if_address_range_is_wired() was leaking a cache reference.
Fixes #5710.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36237 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added vm_debug_copy_page_memory() which copies memory from a potentially not
mapped page.
* debug_{mem,strl}cpy():
- Added "team" parameter for specifying the address space the address are
to be interpreted in.
- When the standard memcpy() (with fault handler) fails, fall back to
vm_debug_copy_page_memory().
* Added debug_is_debugged_team(): Predicate returning true, if the supplied
team_id refers to the same team debug_get_debugged_thread() belongs to.
* Added DebuggedThreadSetter class for scope-based debug_set_debugged_thread().
Made use of it in several debugger functions.
* print_demangled_call() (x86): Fixed unsafe memory access.

Allows KDL stack traces to work correctly again, even if the page daemon has
already unmapped the concerned pages.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36230 a95241bf-73f2-0310-859d-f6bbb57e9c96

delete_area(): When the address space is the kernel address space, we need to
pass stricter allocation flags to VMAddressSpace::{Remove,Delete}Area() or
could deadlock otherwise.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36188 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added vm_[un]wire_page(), which are essentially versions of
[un]lock_memory_etc() optimized for a single page.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36156 a95241bf-73f2-0310-859d-f6bbb57e9c96

* VMArea::Unwire(addr_t, size_t, bool): Don't delete the removed range, but
return it.
* lock_memory_etc(): On error the VMAreaWiredRange object could be leaked.
* [un]lock_memory_etc(): Call VMArea::Unwire() with the cache locked and
explicitly delete the range object after unlocking the cache to avoid
potential deadlocks.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36035 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Removed the VMArea::Wire() version that has to allocate a VMAreaWiredRange.
Since the requirement is that the area's top cache is locked, allocating
memory isn't allowed.
* lock_memory_etc(): Create the VMAreaWiredRange object explicitly before
locking the area's top cache.

Fixes #5680 (deadlocks when using the slab as malloc() backend).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36033 a95241bf-73f2-0310-859d-f6bbb57e9c96

* vm_delete_areas(): Changed return type to void (was status_t and not used).
* _user_map_file(), _user_unmap_memory(): Verify that the address (if given) is
page aligned.
* Reworked memory locking (wiring):
- VMArea does now have a list of wired memory ranges and supports waiting for
a range to be removed.
- vm_soft_fault():
- Added "wirePage" parameter that, if given, makes the function wire the
page and return it.
- Added "wiredRange" parameter (for calls from lock_memory_etc()) and made
sure we never unmap wired pages. This could e.g. happen when a page from a
lower cache was read-mapped and a write fault occurred. Now in such a
situation the function waits for the page to be unwired and restarts.
- All functions that manipulate areas in a way that could affect wired ranges
do now either require the caller to make sure there are no wired ranges in
the way or do that themselves. Added a few wait_if_*_is_wired() helper
functions for that purpose.
- lock_memory_etc():
- Does now also work correctly when the range spans more than one area.
- Adds VMAreaWiredRanges to the affected VMAreas and retains an address
space reference (so that the address space won't be deleted as long as a
wired range exists).
- Resolved TODO: The area's caches are now locked when
increment_page_wired_count() is called.
- Resolved TODO: The race condition due to missing locking after looking up
the page mapping is now prevented. We hold the cache locks (in case the
page is already mapped) and the new vm_soft_fault() parameter allows us
to get the page wired.
- unlock_memory_etc(): Changes symmetrical to those in lock_memory_etc() and
resolved all TODOs.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36030 a95241bf-73f2-0310-859d-f6bbb57e9c96

The "page" and the "cache" kernel debugger commands set a few temporary
variables, now.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35903 a95241bf-73f2-0310-859d-f6bbb57e9c96

Let the compiler decide whether to inline or not.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35821 a95241bf-73f2-0310-859d-f6bbb57e9c96

Boot loader (x86 mmu.cpp):
* Made the page table allocation more flexible. Got rid of sMaxVirtualAddress
and added new virtual_end address to the architecture specific kernel args.
* Increased the virtual space we reserve for the kernel to 16 MB. That
should suffice for quite a while. The previous 2 MB were too tight when
building the kernel with debug info.
* mmu_init(): The way we were translating the BIOS' extended memory map to
our physical ranges arrays was broken. Small gaps between usable memory
ranges would be ignored and instead marked allocated. This worked fine for
the boot loader and during the early kernel initialization, but after the
VM has been fully set up it frees all physical ranges that have not been
claimed otherwise. So those ranges could be entered into the free pages
list and would be used later. This could possibly cause all kinds of weird
problems, probably including ACPI issues. Now we add only the actually
usable ranges to our list.

Kernel:
* vm_page_init(): The pages of the ranges between the usable physical memory
ranges are now marked PAGE_STATE_UNUSED, the allocated ranges
PAGE_STATE_WIRED.
* unmap_and_free_physical_pages(): Don't free pages marked as unused.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35726 a95241bf-73f2-0310-859d-f6bbb57e9c96

* The low resource handler now empties the cache depot's magazines; before,
they were never freed unless the cache was destroyed (I just wondered why
my system would bury >1G in the magazines).
* Made the magazine capacity variable per cache, ie. for larger objects, it's
not a good idea to have 64*CPU buffers lying around in the worst case.
* Furthermore, the create_object_cache_etc()/object_depot_init() now have
arguments for the magazine capacity as well as the maximum number of full
unused magazines.
* By default, you might want to initialize both to zero, as then some hopefully
usable defaults are computed. Otherwise (the only current example is the
vm_page_mapping cache) you can just put in the values you'd want there.
The page mapping cache uses larger values, as its objects are usually
allocated and deleted in larger chunks.
* Beware, though, I couldn't test these changes yet as Qemu didn't like to run
today. I'll test these changes on another machine now.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35601 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Made vm_page::state private and added accessor methods.
* Added kernel tracing for page state transitions.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35538 a95241bf-73f2-0310-859d-f6bbb57e9c96

* map_physical_memory() does now always set a memory type. If none is given (it
needs to be or'ed to the address specification), "uncached" is assumed.
* Set the memory type for the "BIOS" and "DMA" areas to write-back. Not sure, if
that's correct, but that's what was effectively used on my machines before.
* Changed x86_set_mtrrs() and the CPU module hook to also set the default memory
type.
* Rewrote the MTRR computation once more:
- Now we know all used memory ranges, so we are free to extend used ranges
into unused ones in order to simplify them for MTRR setup.
- Leverage the subtractive properties of uncached and write-through ranges to
simplify ranges of any other respectively write-back type.
- Set the default memory type to write-back, so we don't need MTRRs for the
RAM ranges.
- If a new range intersects with an existing one, we no longer just fail.
Instead we use the strictest requirements implied by the ranges. This fixes
#5383.

Overall the new algorithm should be sufficient with far less MTRRs than before
(on my desktop machine 4 are used at maximum, while 8 didn't quite suffice
before). A drawback of the current implementation is that it doesn't deal with
the case of running out of MTRRs at all, which might result in some ranges
having weaker caching/memory ordering properties than requested.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35515 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added warning to vm_map_physical_memory_vecs().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35508 a95241bf-73f2-0310-859d-f6bbb57e9c96

map_page(): Got rid of the activatePage parameter. We always move previously
inactive pages to the active queue. This has the advantage that the page
daemon will keep track of those pages even in idle mode (where it only
processes the active queue).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35498 a95241bf-73f2-0310-859d-f6bbb57e9c96

_user_set_memory_protection(): Missing page access debug markers.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35475 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Removed useless return parameter from vm_remove_all_page_mappings().
* Added vm_clear_page_mapping_accessed_flags() and
vm_remove_all_page_mappings_if_unaccessed(), which combine the functionality
of vm_test_map_activation(), vm_clear_map_flags(), and
vm_remove_all_page_mappings(), thus saving lots of calls to translation map
methods. The backend is the new method
VMTranslationMap::ClearAccessedAndModified().
* Started to make use of the cached page queue and changed the meaning of the
other non-free queues slightly:
- Active queue: Contains mapped pages that have been used recently.
- Inactive queue: Contains mapped pages that have not been used recently. Also
contains unmapped temporary pages.
- Modified queue: Contains unmapped modified pages.
- Cached queue: Contains unmapped unmodified pages (LRU sorted).
Unless we're actually low on memory and actively do paging, modified and
cached queues only contain non-temporary pages. Cached pages are considered
quasi free. They still belong to a cache, but since they are unmodified and
unmapped, they can be freed immediately. And this is what
vm_page_[try_]reserve_pages() do now when there are no more actually free
pages at hand. Essentially this means that pages storing cached file data,
unless mmap()ped, no longer are considered used and don't contribute to page
pressure. Paging will not happen as long there are enough free + cached pages
available.
* Reimplemented the page daemon. It no longer scans all pages, but instead works
the page queues. As long as the free pages situation is harmless, it only
iterates through the active queue and deactivates pages that have not been
used recently. When paging occurs it additionally scans the inactive queue and
frees pages that have not been used recently.
* Changed the page reservation/allocation interface:
vm_page_[try_]reserve_pages(), vm_page_unreserve_pages(), and
vm_page_allocate_page() now take a vm_page_reservation structure pointer.
The reservation functions initialize the structure -- currently consisting
only of a count member for the number of still reserved pages.
vm_page_allocate_page() decrements the count and vm_page_unreserve_pages()
unreserves the remaining pages (if any). Advantages are that reservation/
unreservation mismatches cannot occur anymore, that vm_page_allocate_page()
can verify that the caller has indeed a reserved page left, and that there's
no unnecessary pressure on the free page pool anymore. The only disadvantage
is that the vm_page_reservation object needs to be passed around a bit.
* Reworked the page reservation implementation:
- Got rid of sSystemReservedPages and sPageDeficit. Instead
sUnreservedFreePages now actually contains the number of free pages that
have not yet been reserved (it cannot become negative anymore) and the new
sUnsatisfiedPageReservations contains the number of pages that are still
needed for reservation.
- Threads waiting for reservations do now add themselves to a waiter queue,
which is ordered by descending priority (VM priority and thread priority).
High priority waiters are served first when pages become available.
Fixes #5328.
* cache_prefetch_vnode(): Would reserve one less page than allocated later, if
the size wasn't page aligned.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35393 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Replaced the vm_page_allocate_page*() "pageState" parameter by a more
general "flags" parameter. It encodes the target state of the page -- so
that the page isn't unnecessarily put in the wrong page queue first -- a
flag whether the page should be cleared, and one to indicate whether the
page should be marked busy.
* Added page state PAGE_STATE_CACHED. Not used yet.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35333 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Removed the page state PAGE_STATE_BUSY and instead introduced a vm_page::busy
flag. The obvious advantage is that one can still see what state a page is in
and even move it between states while being marked busy.
* Removed the vm_page::is_dummy flag. Instead we mark marker pages busy, which
in all cases has the same effect. Introduced a vm_page_is_dummy() that can
still check whether a given page is a dummy page.
* vm_page_unreserve_pages(): Before adding to the system reserve make sure
sUnreservedFreePages is non-negative. Otherwise we'd make nonexisting pages
available for allocation. steal_pages() still has the same problem and it
can't be solved that easily.
* map_page(): No longer changes the page state/mark the page unbusy. That's the
caller's responsibility.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35331 a95241bf-73f2-0310-859d-f6bbb57e9c96

vm_create_null_area(): The area was created with B_NO_LOCK which would cause
the wired count of manually mapped pages not to be decremented in
delete_area(), leading to a "pages still has mappings" panic when the slab
allocator's memory manager deleted areas.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35329 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Introduced {malloc,memalign,free}_etc() which take an additional "flags"
argument. They replace the previous special-purpose allocation functions
(malloc_nogrow(), vip_io_request_malloc()).
* Moved the I/O VIP heap to heap.cpp accordingly.
* Added quite a bit of passing around of allocation flags in the VM,
particularly in the VM*AddressSpace classes.
* Fixed IOBuffer::GetNextVirtualVec(): It was ignoring the VIP flag and always
allocated on the normal heap.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35316 a95241bf-73f2-0310-859d-f6bbb57e9c96

* The system now holds back a small reserve of committable memory and pages. The
memory and page reservation functions have a new "priority" parameter that
indicates how deep the function may tap into that reserve. The currently
existing priority levels are "user", "system", and "VIP". The idea is that
user programs should never be able to cause a state that gets the kernel into
trouble due to heavy battling for memory. The "VIP" level (not really used
yet) is intended for allocations that are required to free memory eventually
(in the page writer). More levels are thinkable in the future, like "user real
time" or "user system server".
* Added "priority" parameters to several VMCache methods.
* Replaced the map_backing_store() "unmapAddressRange" parameter by a "flags"
parameter.
* Added area creation flag CREATE_AREA_PRIORITY_VIP and slab allocator flag
CACHE_PRIORITY_VIP indicating the importance of the request.
* Changed most code to pass the right priorities/flags.

These changes already significantly improve the behavior in low memory
situations. I've tested a bit with 64 MB (virtual) RAM and, while not
particularly fast and responsive, the system remains at least usable under high
memory pressure.
As a side effect the slab allocator can now be used as general memory allocator.
Not done by default yet, though.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35295 a95241bf-73f2-0310-859d-f6bbb57e9c96

MemoryManager:
* Added support to do larger raw allocations (up to one large chunk (128 pages))
in the slab areas. For an even larger allocation an area is created (haven't
seen that happen yet, though).
* Added kernel tracing (SLAB_MEMORY_MANAGER_TRACING).
* _FreeArea(): Copy and paste bug: The meta chunks of the to be freed area
would be added to the free lists instead of being removed from them. This
would corrupt the lists and also lead to all kinds of misuse of meta chunks.

object caches:
* Implemented CACHE_ALIGN_ON_SIZE. It is no longer set for all small object
caches, but the block allocator sets it on all power of two size caches.
* object_cache_reserve_internal(): Detect recursion and don't wait in such a
case. The function could deadlock itself, since
HashedObjectCache::CreateSlab() does allocate memory, thus potentially
reentering.
* object_cache_low_memory():
- I missed some returns when reworking that one in r35254, so the function
might stop early and also leave the cache in maintenance mode, which would
cause it to be ignored by object cache resizer and low memory handler from
that point on.
- Since ReturnSlab() potentially unlocks, the conditions weren't quite correct
and too many slabs could be freed.
- Simplified things a bit.
* object_cache_alloc(): Since object_cache_reserve_internal() does potentially
unlock the cache, the situation might have changed and their might not be an
empty slab available, but a partial one. The function would crash.
* Renamed the object cache tracing variable to SLAB_OBJECT_CACHE_TRACING.
* Renamed debugger command "cache_info" to "slab_cache" to avoid confusion with
the VMCache commands.
* ObjectCache::usage was not maintained anymore since I introduced the
MemoryManager. object_cache_get_usage() would thus always return 0 and the
block cache would not be considered cached memory. This was only of
informational relevance, though.

slab allocator misc.:
* Disable the object depots of block allocator caches for object sizes > 2 KB.
Allocations of those sizes aren't so common that the object depots yield any
benefit.
* The slab allocator is now fully self-sufficient. It allocates its bootstrap
memory from the MemoryManager, and the hash tables for HashedObjectCaches use
the block allocator instead of the heap, now.
* Added option to use the slab allocator for malloc() and friends
(USE_SLAB_ALLOCATOR_FOR_MALLOC). Currently disabled. Works in principle and
has virtually no lock contention. Handling for low memory situations is yet
missing, though.
* Improved the output of some debugger commands.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35283 a95241bf-73f2-0310-859d-f6bbb57e9c96

Use large slabs for the page mappings.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35247 a95241bf-73f2-0310-859d-f6bbb57e9c96

Replaced CACHE_DONT_SLEEP by two new flags CACHE_DONT_WAIT_FOR_MEMORY and
CACHE_DONT_LOCK_KERNEL_SPACE. If the former is given, the slab memory manager
does not wait when reserving memory or pages. The latter prevents area
operations. The new flags add a bit of flexibility. E.g. when allocating page
mapping objects for userland areas CACHE_DONT_WAIT_FOR_MEMORY is sufficient,
i.e. the allocation will succeed as long as pages are available.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35246 a95241bf-73f2-0310-859d-f6bbb57e9c96

vm_soft_fault(): map_page() can fail for B_NO_LOCK areas, since it needs to
allocate a page mapping. In that case we do at least have to mark the page
not busy again. Furthermore we enforce the minimum page mappings object cache
reserve, so we'll have more luck on the next fault.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35241 a95241bf-73f2-0310-859d-f6bbb57e9c96

slab allocator:
* Implemented a more elaborated raw memory allocation backend (MemoryManager).
We allocate 8 MB areas whose pages we allocate and map when needed. An area is
divided into equally-sized chunks which form the basic units of allocation. We
have areas with three possible chunk sizes (small, medium, large), which is
basically what the ObjectCache implementations were using anyway.
* Added "uint32 flags" parameter to several of the slab allocator's object
cache and object depot functions. E.g. object_depot_store() potentially wants
to allocate memory for a magazine. But also in pure freeing functions it
might eventually become useful to have those flags, since they could end up
deleting an area, which might not be allowable in all situations. We should
introduce specific flags to indicate that.
* Reworked the block allocator. Since the MemoryManager allocates block-aligned
areas, maintains a hash table for lookup, and maps chunks to object caches,
we can quickly find out which object cache a to be freed allocation belongs
to and thus don't need the boundary tags anymore.
* Reworked the slab boot strap process. We allocate from the initial area only
when really necessary, i.e. when the object cache for the respective
allocation size has not been created yet. A single page is thus sufficient.

other:
* vm_allocate_early(): Added boolean "blockAlign" parameter. If true, the
semantics is the same as for B_ANY_KERNEL_BLOCK_ADDRESS.
* Use an object cache for page mappings. This significantly reduces the
contention on the heap bin locks.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35232 a95241bf-73f2-0310-859d-f6bbb57e9c96

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

Fix build with VM_PAGE_FAULT_TRACING enabled.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35187 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Split the slab allocator code into separate source files and C++-ified
things a bit.
* Some style cleanup.
* The object depot does now have a cookie that will be passed to the return
hook.
* Fixed object_cache_return_object_wrapper() using the new cookie.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35174 a95241bf-73f2-0310-859d-f6bbb57e9c96

vm_page no longer points directly to its containing cache, but rather to a
VMCacheRef object which points to the cache. This allows to optimize
VMCache::MoveAllPages(), since it no longer needs to iterate over all pages
to adjust their cache pointer. It can simple swap the cache refs of the two
caches instead.

Reduces the total -j8 Haiku image build time only marginally. The kernel time
drops almost 10%, though.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35155 a95241bf-73f2-0310-859d-f6bbb57e9c96

* VMCache: Added a UserData attribute which can be used by the lock holder.
* Added "bool consumerLocked" parameter to VMCache::Unlock() and
ReleaseRefAndUnlock(). Since Unlock() may cause the cache to be merged with
a consumer cache, the flag is needed to prevent a deadlock in case the
caller still holds a lock to the consumer. Hasn't been a problem yet, since
that situation never occurred.
* VMCacheChainLocker: Reversed unlocking order to bottom-up. The other
direction could cause a deadlock in case caches would be merged, since the
locking order would be reversed. The way VMCacheChainLocker was used this
didn't happen, though.
* fault_get_page(): While copying a page from a lower cache to the top cache,
we do now unlock all caches but the top one, so we don't unnecessarily
kill concurrency.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35153 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added vm_page::accessed flag. Works analogously to vm_page::modified.
* Reorganized the code for [un]mapping pages:
- Added new VMTranslationMap::Unmap{Area,Page[s]}() which essentially do what
vm_unmap_page[s]() did before, just in the architecture specific code, which
allows for specific optimizations. UnmapArea() is for the special case that
the complete area is unmapped. Particularly in case the address space is
deleted, some work can be saved. Several TODOs could be slain.
- Since they are only used within vm.cpp vm_map_page() and vm_unmap_page[s]()
are now static and have lost their prefix (and the "preserveModified"
parameter).
* Added VMTranslationMap::Protect{Page,Area}(). They are just inline wrappers
for Protect().
* X86VMTranslationMap::Protect(): Make sure not to accidentally clear the
accessed/dirty flags.
* X86VMTranslationMap::Unmap()/Protect(): Make page table skipping actually
work. It was only skipping to the next page.
* Adjusted the PPC code to at least compile.

No measurable effect for the -j8 Haiku image build time, though the kernel time
drops minimally.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35089 a95241bf-73f2-0310-859d-f6bbb57e9c96

Refactored vm_translation_map:
* Pulled the physical page mapping functions out of vm_translation_map into
a new interface VMPhysicalPageMapper.
* Renamed vm_translation_map to VMTranslationMap and made it a proper C++
class. The functions in the operations vector have become methods.
* Added class GenericVMPhysicalPageMapper implementing VMPhysicalPageMapper
as far as possible (without actually writing new code).
* Adjusted the x86 and the PPC specifics accordingly (untested for the
latter). For the other architectures the build is, I'm afraid, seriously
broken.

The next steps will modify and extend the VMTranslationMap interface, so that
it will be possible to fix the bugs in vm_unmap_page[s]() and employ
architecture specific optimizations.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35066 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added boolean "alreadyWired" parameter to vm_map_physical_memory().
* ioapic_init(): map_physical_memory() was called for already mapped
addresses. This worked fine, but only because the x86 page mapping code
didn't mind.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35059 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added TODOs.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35056 a95241bf-73f2-0310-859d-f6bbb57e9c96

Should have been part of r35023: Introduction of the vm_page::modified flag.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35024 a95241bf-73f2-0310-859d-f6bbb57e9c96

PAGE_TYPE_GUARD was unused and for the other two types a simple one bit flag
suffices. Therefore replaced vm_page::type by vm_page::is_dummy.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35013 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Made VMCacheChainLocker more flexible (added unlocking destructor and
LockAllSourceCaches()) and moved it to the beginning of the file.
* Removed sMappingLock and adjusted the locking policy for mapping/unmapping
pages: Since holding the lock of the affected pages' caches is already
required, that does now protect the page's mappings, too. The area mappings
are protected by the translation map lock, which we always acquire anyway
when mapping, unmapping, or looking up mappings.

The change results in a -j8 Haiku image build speedup of almost 10%. The
total kernel time drops almost 30%.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34965 a95241bf-73f2-0310-859d-f6bbb57e9c96

unmap_and_free_physical_pages(): Don't try to free already free pages.
Apparently (at least when running in VMware >=2) the boot loader can still
map the same physical page more than once -- in the ACPI or HPET code I
suppose -- which would lead to this situation.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34954 a95241bf-73f2-0310-859d-f6bbb57e9c96

Changed sAreaCacheLock from mutex to rw_lock. This reduces the lock's
contention about two orders of magnitude. Most of it seems to be taken over
by other locks, though. Yields only small improvements for the -j8 Haiku
image build.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34937 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added new debug feature (DEBUG_PAGE_ACCESS) to detect invalid concurrent
access to a vm_page. It is basically an atomically accessed thread ID field
in the vm_page structure, which is explicitly set by macros marking the
critical sections. As a first positive effect I had to review quite a bit of
code and found several issues.
* Added several TODOs and comments. Some harmless ones, but also a few
troublesome ones in vm.cpp regarding page unmapping.
* file_cache: PrecacheIO::Prepare()/read_into_cache: Removed superfluous
vm_page_allocate_page() return value checks. It cannot fail anymore.
* Removed the heavily contended "pages" lock. We use different policies now:
- sModifiedTemporaryPages is accessed atomically.
- sPageDeficitLock and sFreePageCondition are protected by a new mutex.
- The page queues have individual locks (mutexes).
- Renamed set_page_state_nolock() to set_page_state(). Unless the caller says
otherwise, it does now lock the affected pages queues itself. Also changed
the return value to void -- we panic() anyway.
* set_page_state(): Add free/clear pages to the beginning of their respective
queues as this is more cache-friendly.
* Pages with the states PAGE_STATE_WIRED or PAGE_STATE_UNUSED are no longer
in any queue. They were in the "active" queue, but there's no good reason
to have them there. In case we decide to let the page daemon work the queues
(like FreeBSD) they would just be in the way.
* Pulled the common part of vm_page_allocate_page_run[_no_base]() into a helper
function. Also fixed a bug I introduced previously: The functions must not
vm_page_unreserve_pages() on success, since they remove the pages from the
free/clear queue without decrementing sUnreservedFreePages.
* vm_page_set_state(): Changed return type to void. The function cannot really
fail and no-one was checking it anyway.
* vm_page_free(), vm_page_set_state(): Added assertion: The page must not be
free/clear before. This is implied by the policy that no-one is allowed to
access free/clear pages without holding the respective queue's lock, which is
not the case at this point. This found the bug fixed in r34912.
* vm_page_requeue(): Added general assertions. panic() when requeuing of
free/clear pages is requested. Same reason as above.
* vm_clone_area(), B_FULL_LOCK case: Don't map busy pages. The implementation is
still not correct, though.

My usual -j8 Haiku build test runs another 10% faster, now. The total kernel
time drops about 18%. As hoped the new locks have only a fraction of the old
"pages" lock contention. Other locks lead the "most wanted list" now.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34933 a95241bf-73f2-0310-859d-f6bbb57e9c96

unmap_and_free_physical_pages(): Added missing check whether the page
mapping is actually present. This would have resulted in page 0 being freed
over and over again, if we hadn't also incorrectly tried to look up the page
by the virtual instead of the physical address. So we were actually freeing
random pages. Fortunately the virtual addresses are kernel addresses, so that
the affected pages lay beyond 2 GB and probably weren't used at this point
yet.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34912 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Andreas Faerber (small changes by myself):
* Fix compilation with tracing enabled.

Thanks! Fixes ticket #5183.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34862 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Andreas Faerber:
* Fix a warning in VM tracing output, which prevented the compilation since
warnings are treated as errors.

Thanks!


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34855 a95241bf-73f2-0310-859d-f6bbb57e9c96

* agp_gart(): Use vm_page_[un]reserve_pages().
* Removed unused vm_page_allocate_pages().
* Removed now unused (always true) "reserved" parameter from
vm_page_allocate_page().
* Removed unused (always false) "stealActive" parameter from steal_page().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34836 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added method VMCache::TransferAreas() moving areas from one cache to
another. The code originates from vm_copy_on_write_area(). We now generate
the VM cache tracing entries, though.
* count_writable_areas() -> VMCache::CountWritableAreas()
* Added debugger command "cache_stack" which is enabled when VM cache tracing
is enabled. It prints the source caches of a given cache or area at the
time of a specified tracing entry.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34751 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Enforce that the caller of transfer_area() owns the area - this fixes some
mean crashes with the media_server version I just checked in.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34556 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added a simple mechanism to wait for events to VMCache. WaitForPageEvents()
waits for certain events on a given page, NotifyPageEvents() wakes up
waiting threads respectively.
* Used the new feature instead of condition variables for waiting on busy
pages. We save publishing and unpublishing of a condition variable whenever
a page is marked busy. There's only something to do, if there's at least
one thread waiting in the list of the respective cache. The general
assumption is that this is only rarely the case and even if it happens,
there should be only very few threads.
* Added an apparently missing notification in cache_io(). At least I didn't
see the reason for it not being there.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34537 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added 64 bit TODO. We'll probably have to change the interface (cookie type)
of get_next_area_info() and others.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34533 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Renamed VMAddressSpace::ResizeArea{Head,Tail}() to ShrinkArea{Head,Tail}()
to clarify that they never enlarge the area.
* Reimplemented VMKernelAddressSpace. It is somewhat inspired by Bonwick's
vmem resource allocator (though we have different requirements):
- We consider the complete address space to be divided into contiguous
ranges of type free, reserved, or area, each range being represented by
a VMKernelAddressRange object.
- The range objects are managed in an AVL tree and a doubly linked list
(the latter only for faster iteration) sorted by address. This provides
O(log(n)) lookup, insertion and removal.
- For each power of two size we maintain a list of free ranges of at least
that size. Thus for the most common case of B_ANY*_ADDRESS area
allocation, we find a free range in constant time (the rest of the
processing being O(log(n))) with a rather good fit. This should also
help avoiding address space fragmentation.
While the new implementation should be faster, particularly with an
increasing number of areas, I couldn't measure any difference in the -j2
haiku build. From a cursory test the -j8 build hasn't tangibly benefitted
either.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34528 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added VMArea subclasses VM{Kernel,User}Area and moved the address space list
link to them.
* VM{Kernel,User}AddressSpace manage the respective VMArea subclass now, and
VMAddressSpace has grown factory methods {Create,Delete}Area.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34493 a95241bf-73f2-0310-859d-f6bbb57e9c96

Moved all knowledge of reserved areas from vm.cpp to VMAddressSpace. It's a
pure address space feature, so it should be handled there.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34491 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added VMAddressSpace::ResizeArea{Head,Tail}() to adjust an area's base
and size.
* Made VMArea::Set{Base,Size}() private and made VMAddressSpace a friend.
In vm.cpp the new VMAddressSpace::ResizeArea{Head,Tail}() are used
instead.
Finally all address space changes happen in VMAddressSpace only. *phew*
Now it's ready to be thoroughly butchered. :-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34467 a95241bf-73f2-0310-859d-f6bbb57e9c96

Made the VMArea fields base and size private and added accessors instead.
This makes it more explicit where the fields are modified.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34464 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Changed the address space area list to doubly linked. The reason is to
simplify migration of the area management, but as a side effect, it also
makes area deletion O(1) (instead of O(n), n == number of areas in the
address space).
* Moved more area management functionality from vm.cpp to VMAddressSpace and
VMArea structure creation to VMArea. Made the list and list link members
itself private.
* VMAddressSpace tracks its amount of free space, now. This also replaces
the previous mechanism to do that only for the kernel address space. It
was broken anyway, since delete_area() subtracted the area size instead of
adding it.
* vm_free_unused_boot_loader_range():
- lastEnd could be set to a value < start, which could cause memory
outside of the given range to be unmapped. Haven't checked whether this
could happen in practice -- if so, it would be seriously unhealthy.
- The range between the end of the last area in the range and the end of
the range would never be freed.
- Fixed potential integer overflows when computing addresses.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34459 a95241bf-73f2-0310-859d-f6bbb57e9c96

Moved the three address space locker classes into a separate pair of
header/source files.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34451 a95241bf-73f2-0310-859d-f6bbb57e9c96

Created VMArea.{h,cpp} and moved VMArea and the global area hash table (new
class VMAreaHash) there.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34450 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved the VM headers into subdirectory vm/.
* Renamed vm_cache.h/vm_address_space.h to VMCache.h/VMAddressSpace.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34449 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved VMAddressSpace definition to vm_address_space.h.
* "Classified" VMAddressSpace, i.e. turned the vm_address_space_*() functions
into methods, made all attributes (but "areas") private, and added
accessors.
* Also turned the vm.cpp functions vm_area_lookup() and
remove_area_from_address_space() into VMAddressSpace methods. The rest of
the area management functionality will follow soon.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34447 a95241bf-73f2-0310-859d-f6bbb57e9c96

Finished renaming of vm_cache to VMCache.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34424 a95241bf-73f2-0310-859d-f6bbb57e9c96

vm_area -> VMArea


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34423 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed vm_address_space to VMAddressSpace.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34422 a95241bf-73f2-0310-859d-f6bbb57e9c96

* The kernel's address space is now also a resource that is known to the low
resource manager.
* Could be drastically improved, though, by taking the fragmentation into
account.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34309 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Minor clarification.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34307 a95241bf-73f2-0310-859d-f6bbb57e9c96

* r33436 broke user_strlcpy() semantics: with a size of 0, "to" can be ignored,
and it's still a valid call.
* This fixes ktrace_printf() from userland.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33934 a95241bf-73f2-0310-859d-f6bbb57e9c96

* While r33037 fixed the alignment of areas put into reserved areas, it actually
broke their placement at the end of the reserved area, which was the main
reason #4778 happened so often (it would have been more hidden else).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33598 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Reserved areas would also be created in existing reserved areas in case the
space was becoming tight. This actually fixes #4778.
* Fixed overflow problem in find_reserved_area().
* Cleaned up the test app, added license.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33597 a95241bf-73f2-0310-859d-f6bbb57e9c96

* r33037 broke the handling of reserved areas, more specifically, it ignored
the RESERVED_AVOID_BASE flag of those, and introduced a way to fill them
from the start. This caused #4778.
* Turned IS_VALID_SPOT() macro into an inline function.
* Removed already resolved TODO comment.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33581 a95241bf-73f2-0310-859d-f6bbb57e9c96

Introduce vm_map_physical_memory_vecs. It is like vm_map_physical_memory but
takes a list of iovecs describing the physical pages to be mapped. With it one
can map a set of physically disjoint pages into one linear virtual range. This
is a private API right now, but we might want to make it public as
map_physical_memory_vecs alongside map_physical_memory.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33523 a95241bf-73f2-0310-859d-f6bbb57e9c96

Amended the {user,debug}_strlcpy() fix: Due to the strlcpy() semantics to
always return the source string length, we can't really prevent an overflow
of the source address.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33489 a95241bf-73f2-0310-859d-f6bbb57e9c96

Made the {debug,user}_{mem,strl}cpy() and user_memset() functions deal with
address overflows. Apparently at least the x86 string instructions generate
a general protection fault instead of a page fault, and we only use the fault
handler in the latter case (maybe we should change that, too). Fixes #4714.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33436 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Also take into account that the alignment due to B_ANY_KERNEL_BLOCK_ADDRESS
can cause overflows.
* Added a generic IS_VALID_SPOT() macro that checks for overflows and checks if
the area will fit with the given constraints.
* Use the macro to simplify the places where these checks are necessary.
* Use the provided "end" limit instead of the address space end. It currently
doesn't matter but makes more sense.
* Rename newBase variables to alignedBase as that's what they are.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33061 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Change the way we check for enough available space when searching for spots
to insert areas so we don't overflow.
* Consequently use the area end (base + size - 1) where appropriate which
prevents overflows in a few places.
* Properly check for reaching the address space end.
* If we've already found a spot we don't need to recheck if we've found one.
* Simplify the B_EXACT_ADDRESS checks down to a simpler single if statement
instead of the four seperate ones.
* Properly calculate the search end for B_EXACT_ADDRESS as well, it's also
base + size - 1.
* Block the full last page now that this actually works without overflowing.
* Some style changes and added spacing.

This should now really fix #2550. Previously the overflow protection didn't
actually work because on allocation we overflowed and completely missed the
protecting area.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33037 a95241bf-73f2-0310-859d-f6bbb57e9c96

Style fix. I really tried hard, but still failed...


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33034 a95241bf-73f2-0310-859d-f6bbb57e9c96

Block the very last page of kernel address space. The problem here is that non
of the VM functions handling areas are overflow safe. If an area is created that
spans across the last page many places will run into an integer overflow. This
mostly concerns the area allocation path in find_and_insert_area_slot() and also
vm_create_anonymous_area() where the loop for mapping pages for B_FULL_LOCK
areas overflows and runs more times than it should leading to #2550.
This could be seen as a workaround. The real fix would be to make everything
overflow safe. The thing is that this does also concern the user of the area
which could easily have forgotten to check for overflows as well, so I am a bit
uneasy with handing out areas that could easily lead to such hard to debug
problems. Since this is really an edge case and this single step safes quite a
bit of extra checks I'd actually be OK with keeping it that way.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33032 a95241bf-73f2-0310-859d-f6bbb57e9c96

Also check for read-protection of an area. Adjusted naming from read-only to
write-protected and read-protected.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33031 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implement a vm_block_address_range() function which creates an area with no
mapped pages and a non-read and non-write protection to block a certain address
range from being used by anything.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33030 a95241bf-73f2-0310-859d-f6bbb57e9c96

* area_for() now also returns the area ID for kernel areas if they are
accessible to the userland - this fixes #2405 (ie. MediaPlayer overlay now
works).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32135 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Renamed the ROUNDOWN macro to ROUNDDOWN. Also changed the implementation of
ROUNDUP to use '*' and '/' -- the compiler will optimize that for powers of
two anyway and this implementation works for other numbers as well.
* The thread::fault_handler use in C[++] code was broken with gcc 4. At least
when other functions were invoked. Trying to trick the compiler wasn't a
particularly good idea anyway, since the next compiler version could break
the trick again. So the general policy is to use the fault handlers only in
assembly code where we have full control. Changed that for x86 (save for the
vm86 mode, which has a similar mechanism), but not for the other
architectures.
* Introduced fault_handler, fault_handler_stack_pointer, and fault_jump_buffer
fields in the cpu_ent structure, which must be used instead of
thread::fault_handler in the kernel debugger. Consequently user_memcpy() must
not be used in the kernel debugger either. Introduced a debug_memcpy()
instead.
* Introduced debug_call_with_fault_handler() function which calls a function
in a setjmp() and fault handler context. The architecture specific backend
arch_debug_call_with_fault_handler() has only been implemented for x86 yet.
* Introduced debug_is_kernel_memory_accessible() for use in the kernel
debugger. It determines whether a range of memory can be accessed in the
way specified. The architecture specific back end
arch_vm_translation_map_is_kernel_page_accessible() has only been implemented
for x86 yet.
* Added arch_debug_unset_current_thread() (only implemented for x86) to unset
the current thread pointer in the kernel debugger. When entering the kernel
debugger we do some basic sanity checks of the currently set thread structure
and unset it, if they fail. This allows certain commands (most importantly
the stack trace command) to avoid accessing the thread structure.
* x86: When handling a double fault, we do now install a special handler for
page faults. This allows us to gracefully catch faulting commands, even if
e.g. the thread structure is toast.

We are now in much better shape to deal with double faults. Hopefully avoiding
the triple faults that some people have been experiencing on their hardware
and ideally even allowing to use the kernel debugger normally.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32073 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added explicit physical address parameter to vm_create_anonymous_area() and
create_area_etc(). 0 for the default behavior.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31941 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Introduced CREATE_AREA_DONT_CLEAR create_area_etc() flag, which allows the
call to fetch non-clear pages.
* B_PHYSICAL_BASE_ADDRESS does now imply B_CONTIGUOUS.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31932 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31915 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Work-in-progress on a kernel profile service that can be evaluated from
userland afterwards.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31621 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Renamed _kern_reserve_heap_address_range() to _kern_reserve_address_range(),
and added a _kern_unreserve_address_range() as well.
* The runtime loader now reserves the space needed for all its areas first
to make sure there is enough space left for all areas of a single image.
* This also fixes the final part of bug #4008.
* Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31115 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added an "unmapAddressRange" argument to the file mapping syscall. This is
the first part of making the runtime loader behave itself; it should already
make Clockwerk run okay with any number of translators (even if not all of
them will work yet).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31113 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Reworked vm_soft_fault() and friends:
- While walking down the cache chain, we keep all upper caches locked.
- When we have to unlock -- when waiting for a busy page or reading a page in
-- we unlock completely, including the address space, and restart
vm_soft_fault().
- Folded fault_get_page() and fault_find_page() into one.
This simplifies and improves things considerably:
- We no longer need dummy pages.
- We no longer need vm_area::no_cache_change.
- #2710 is fixed, since we no longer hold the address space lock while
waiting.
* vm_soft_fault(): When we have found our page, we first check whether a page
is already mapped at the address. If it is already our page, we just change
its protection. If not, we unmap it first. Fixes race conditions when multiple
threads fault at the same address at the same time.
* fault_get_page(): When copying a read-only page from a lower cache, no longer
mark it active, since at least for the fault area it is shadowed from then on.
* vm_set_area_protection(): Fixed potential overflow for in the
vm_translation_map::protect() call.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30911 a95241bf-73f2-0310-859d-f6bbb57e9c96

Disabled the stack traces on unhandled userland page faults. As was already
known those can cause a deadlock. Besides, when the debug server is running,
it prints an even nicer stack trace. Not removing the code yet to make things
easier for architectures on which we don't have a userland yet.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30877 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fixed several problems of the prefetching code:
* Did claim to have reserved pages when calling vm_page_allocate_page(), but
didn't have any (copy&paste bug). We cannot use it without reserved pages,
as we need to call vm_page_allocate_page() with a cache locked.
* No longer use low_resource_state() to determine whether to precache or not,
but use the new vm_page_num_used_pages() instead.
* Also don't (try to) precache when the cache already has more than 2/3 of its
pages to safe some unnecessary work.
* The size to precache was limited to the file size incorrectly.
* When precaching failed, the cache reference was not released.
* The precaching started one page too late, causing bug #3835.
* Reenabled precaching.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30515 a95241bf-73f2-0310-859d-f6bbb57e9c96

Disable pre-fetching until we fix bug #3835.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30477 a95241bf-73f2-0310-859d-f6bbb57e9c96

axeld:
* Implemented a way to do asynchronous pre-fetching when mapping files.
* There are slight code duplications in some places that could benefit
from cleaning up, but nothing too bad.
* Implementing smarter ways to trigger prefetching and more analysis of
the situations in the kernel would be nice. Currently up to 10 MB
of every mapped file are pre-fetched without further analysis.
* The speed improvement is nice for certain operations. On our test
system (real hardware), Firefox took 9 seconds from being launched
to display a window. Now it takes 5 seconds. Both measurements
right after booting. The same system took 35 seconds from launching
Haiku in the GRUB menu to displaying the Tracker desktop background
image. Now it takes 27 seconds.
* We didn't have the chance to check out the effects of this on the
CD boot, but potentially, they could speed it up a lot.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30465 a95241bf-73f2-0310-859d-f6bbb57e9c96

zooey + bonefish:
* optimized unmapping of a single page that was rather inefficient
for large areas

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29978 a95241bf-73f2-0310-859d-f6bbb57e9c96

* One should not rely on the comma operator being evaluated right-to-left as
it was done in SAS/C... (yeah, that was ages ago). This fixes bug #2030.
* Also, we should probably check if the area we're about to shrink/remove
actually is a reserved area.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29605 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Worked over the "area" KDL command to make it more useful, and easier to use.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29503 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Cleanup, no functional change.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29478 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Renamed src/system/kernel/device_manager/io_requests.{h,cpp} to
IORequest.{h,cpp}.
* Introduced public <io_requests.h> header. Currently it only declares the
single function BFS uses.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29446 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fixing warnings under GCC4 in preparation to enable -Werror there as well:
* Replaced the use of offsetof() for structs that aren't PODs. Add a
offset_of_member() macro to util/khash.h because that's what it's used for
in our cases.
* Change the signature of add_debugger_command()/remove_debugger_command() on
GCC > 2 to avoid the depricated conversion from string constants to char *.
* Adding some "suggested" parenthesis. I know that not everyone likes that, but
it pointed out at least one bug that is fixed here as well.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29113 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added kernel tracing for page faults.
* vm_clone_area() does now set the B_SHARED_AREA flag on both the source
and the cloned area. This is necessary, since it would no longer be
guaranteed that areas are backed by leaf caches only (after
fork()ing), which doesn't work with our cache merging strategy.
Fixes #2605.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28296 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved more debug macros to kernel_debug_config.h.
* Turned the checks for all those macros to "#if"s instead of "#ifdef"s.
* Introduced macro KDEBUG_LEVEL which serves as a master setting.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28248 a95241bf-73f2-0310-859d-f6bbb57e9c96

Consistently use KDEBUG. It is always defined and therefore must be
checked with "#if".


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28247 a95241bf-73f2-0310-859d-f6bbb57e9c96

* 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

* Moved memset_physical() to vm.cpp and made it available in the kernel.
* Added memcpy_to_physical().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28219 a95241bf-73f2-0310-859d-f6bbb57e9c96

* 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

* Added kernel tracing for the page daemon and the page writer.
* Added some commented out debug output in vm.cpp.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27971 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added "flags" parameter to VMCache::Read().
* Use the new VMCache::Read() flags parameter to directly read into the
physical page in the page fault handler instead of mapping it first.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27966 a95241bf-73f2-0310-859d-f6bbb57e9c96

- add team id on a TRACE()
- try to accomodate for low ram systems by making the first kernel heap allocation smaller


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27943 a95241bf-73f2-0310-859d-f6bbb57e9c96

Changed the handling for hardware-caused terminal signals:
* No longer send a SIGKILL when a page fault occurred, there was no
signal handler, and the debugger told us to continue as usual. Instead
we send a SIGSEGV. Instead in handle_signal() when not in the main
thread and there's no handler for the signal, we first send the main
thread a SIGKILL before letting the thread die.
So in cases where the main thread caused an unhandled page fault, the
team will die from the SIGSEGV, now. This fixes bug #2773.
* For the other hardware-caused signals we do now do the same as in case
of page faults, i.e. we first check whether the thread has a handler
for the signal in question. If so, we don't notify the debugger, but
send the signal right away.
* B_GENERAL_PROTECTION_FAULT is translated to SIGILL now. Seems better
than SIGKILL.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27757 a95241bf-73f2-0310-859d-f6bbb57e9c96

Let the boot loader set the kernel image's name.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27754 a95241bf-73f2-0310-859d-f6bbb57e9c96

Reverted r27685, r27676, r27665, and r27664, the changes related to
letting the boot loader provide full paths for the pre-loaded images.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27753 a95241bf-73f2-0310-859d-f6bbb57e9c96

The boot loader does now set the names of the images it loads to the
full paths.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27665 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Implemented a (private for now) get_system_info_etc() call, that can retrieve
various system information.
* Implemented retrieving some VM stats via this call.
* The VM now maintains a page fault counter, and sets system_info::page_faults
accordingly.
* Added a (pretty simple) "vmstat" command line app.
* Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27597 a95241bf-73f2-0310-859d-f6bbb57e9c96

When mapping a file into memory we do now immediately map all active
pages into the team's address space. Doing that is relatively cheap and
saves later page faults.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27380 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added a "flags" parameter to vm_create_anonymous_area() and
create_area_etc().
* When the new flag CREATE_AREA_DONT_WAIT is specified, the functions
don't wait for memory or pages to become available. They fail
immediately instead.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27117 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added object_cache_set_minimum_reserve() which sets the minimal number
of free objects an object cache should try to have ready. If the number
of free objects drops below the threshold, a new urgent priority thread
is asked to asynchronously resize the object cache (pretty similar to
the heap grower thread). Such a mechanism is necessary for code paths
that are supposed to free pages, but may need memory themselves (like
the swap support).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27100 a95241bf-73f2-0310-859d-f6bbb57e9c96

vm_remove_all_page_mappings(): Decrement the mapped pages count only, if
the page was really mapped before. Fixes bug #2585.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26876 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Implemented mprotect(). A vm_area does now have an optional array
specifying the protection of each page (4 bits per page).
* Added no-op implementation of posix_madvise().
* Replaced a few "addr_t size" parameters by "size_t size".


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26871 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Improved some output and coding style.
* If a segment violation occurs, we do now check whether the thread in
question has a handler for SIGSEGV. If so, we just send it the signal.
Otherwise we notify the debugger as before.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26851 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved the incrementing/decrementing of vm_page::wired_count into
dedicated functions.
* Introduced gMappedPagesCount variable which counts the total number of
physical pages that are mapped.
* Added vm_page_get_stats() which fills in the memory related part of
the system_info structure. Used and cached pages are computed
differently, now. The "available" (== not committed) memory is no
longer used for the computation as it doesn't say anything about the
actually used/free pages (with swap support enabled it is even
less meaningful, since we first commit swap space when possible).
We do also consider the memory used by the block cache as cached
pages, now. All in all these changes should fix the memory statistics
reported by get_system_info(), IOW bug #2574.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26837 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Changed the meaning of the {KERNEL,USER}_STACK_SIZE macros to not
include the guard pages. Adjusted the kernel and boot loader code
accordingly -- the guard pages size is added/not removed respectively.
The stack size passed to _kern_spawn_thread() is now the actually usable
size, and it is no longer possible to specify a size smaller than or
equal to the guard pages size.
* vm_create_anonymous_area(): Precommit two pages maximum -- a stack with
only one page usable size obviously doesn't need two pages.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26819 a95241bf-73f2-0310-859d-f6bbb57e9c96

vm_page_fault(): Only put the address space, if we actually got one.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26774 a95241bf-73f2-0310-859d-f6bbb57e9c96

vm_create_anonymous_area():
* Moved reservation of memory for the "locked" cases upfront.
Particularly if the would-be area is a kernel area, we don't want the
address space to be write locked while doing that, since that would
block the low memory handler.
* For full lock areas the pages are reserved upfront, too. The reasoning
is similar. Reserve the pages needed by the translation map backend for
mapping the area pages there too.
* Moved the cache locking/unlocking out of the individual cases. All
want to have the cache locked the whole time, now.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26741 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Renamed kernel_startup to gKernelStartup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26731 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added TODO -- food for thoughts.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26711 a95241bf-73f2-0310-859d-f6bbb57e9c96

Removed pointless check. vm_page_allocate_page() only returns NULL, when
an invalid page state was supplied. The comment was misleading too,
as the pages weren't reserved upfront.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26650 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added TODOs in lock_memory_etc.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26629 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added "boolean getNewReference" parameter to the vm_address_space*
versions of the AddressSpaceReadLocker constructor and SetTo(). When
true it will get a new reference to the address space.
* Changed vm_soft_fault(): Now it gets the address space as a
parameter (for page faults getting it happens in vm_page_fault()).
This should fix lock_memory_etc() for other teams -- it used the
correct address space before, but the invoked vm_soft_fault() always
used the current team's address space.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26628 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Zhao Shuai with changes by myself:
* Init swap support in main().
* Added "bool swappable" parameter to
VMCacheFactory::CreateAnonymousCache(). A cache supporting swapping
is created when true. Adjusted invocations accordingly.
* The page writer does now write non-locked swappable pages (when
memory is low).
* Fixed header guard of VMAnonymousNoSwapCache.h.
* Swap support is compiled conditionally, controlled by the
ENABLE_SWAP_SUPPORT in src/system/kernel/vm/VMAnonymousCache.h. It is
disabled ATM. Since no swap files are added, it wouldn't have much
effect anyway.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26625 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added function get_memory_map_etc() which works similar to
get_memory_map(), but has a saner semantics and allows specifying a
team.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26600 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Replaced the sAreaHashLock with an rw_lock.
* As this was the last user of the READ_COUNT/WRITE_COUNT definitions in
vm_priv.h, I removed those as well.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26582 a95241bf-73f2-0310-859d-f6bbb57e9c96

* bfs_fsync() was the only place which could cause the
fs_vnode_ops::write_pages() to be called with fsReenter = true. Since
this is no longer the case, the argument has become superfluous. For
read_pages() it always was. Removed the argument from the functions
and all functions that propagated it.
* Some whitespace at the end of lines was removed.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26579 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Replaced the simplistic semaphore based R/W lock in the vm_address_space with
the new rw_lock locking primitive.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26578 a95241bf-73f2-0310-859d-f6bbb57e9c96

Merged branch haiku/branches/developer/bonefish/vm into trunk. This
introduces the following relevant changes:
* VMCache:
- Renamed vm_cache to VMCache, merged it with vm_store and made it a
C++ class with virtual methods (replacing the store operations).
Turned the different store implementations into subclasses.
- Introduced MergeStore() callback, changed semantics of Commit().
- Changed locking and referencing semantics. A reference can only be
acquired/released with the cache locked. An unreferenced cache is
deleted and a mergeable cache merged when it is unlocked. This
removes the "busy" state of a cache and simplifies the page fault
code.
* Added VMAnonymousCache, which will implement swap support (work by
Zhao Shuai). It is not integrated and used yet, though.
* Enabled the mutex/recursive lock holder asserts.
* Fixed DoublyLinkedList::Swap().
* Generalized the low memory handler to a low resource handler. And made
semaphores and reserved memory handled resources. Made
vm_try_resource_memory() optionally wait (with timeout), and used that
feature to reserve memory for areas.
...


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26572 a95241bf-73f2-0310-859d-f6bbb57e9c96

No wethers in here anymore.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26487 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added B_PHYSICAL_BASE_ADDRESS address specification for anonymous areas.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26456 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added [un]lock_memory_etc() versions that accept a team_id as first argument.
This allows drivers to lock the memory outside of the original team context.
* create_area_etc() got a struct team as first argument, but that should have
been a team_id.
* Removed delete_area_etc() - there is already vm_delete_area() doing the same
thing.
* Renamed vm_get_address_space_by_id() to vm_get_address_space(), as there is
no other method of getting an address space.
* Removed erroneous white space.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26455 a95241bf-73f2-0310-859d-f6bbb57e9c96

Changes related to the "caches" command:
* The table used for sorting the caches could be too small for the
number of caches in the system. We never checked that, which could
cause a crash or triple faults when invoking the command.
* We now allocate the table as an area. Also increased the table size to
102400 entries.
* Also print the committed memory for non-RAM caches, if they are the
root cache of a cache tree that has committed memory.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26333 a95241bf-73f2-0310-859d-f6bbb57e9c96

Remove a few unused variables.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26249 a95241bf-73f2-0310-859d-f6bbb57e9c96

fault_find_page(): When the source of the top cache is busy, we may
find our own dummy page. This is equivalent to not finding a page at
all. Fixes #2471.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26248 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Avoid calling vm_unreserve_memory() if there is no change in the commited
size. Removes a bit of overhead (call and mutex_lock / mutex_unlock).
* Don't fail if there is exactly enough memory available to satisfy the
reserve request. Not that it would really matter as it's rather an edge case...

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26246 a95241bf-73f2-0310-859d-f6bbb57e9c96

"caches" also prints the total number of pages assigned to caches and
the total amount of committed memory.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26165 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Replaced the global cache pages hash table by an IteratableSplayTree
per cache.
* Changed the strategy vm_cache_acquire_page_cache_ref() uses to ensure
that the cache isn't deleted while trying to get a reference. Instead
of the global cache pages hash table lock, it holds the global cache
list lock now. We acquire + release this lock in delete_cache() after
removing all pages and just before deleting the object.
* Some small optimizations using the property that the cache's pages are
ordered, now (vm_cache_resize(), vm_page_write_modified_page_range(),
vm_page_schedule_write_page_range()).
* Replaced some code counting a cache's pages by simply using
vm_cache::page_count.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26160 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added malloc_nogrow() function that does allocation without triggering or
waiting for a heap grow.
* Use that nogrow version in the VM code to avoid a deadlock with the address
space lock when a grow operation would try to create an area while a malloc
happened from such a function in the VM.
* When waiting for a grow to happen, notify the waiting thread from the grower
also if it failed to allocate a new heap. Otherwise a thread would just sit
there and wait until another thread requested growing too and that one
succeeded (or just forever in the worst case).
* Make the dedicated grow heap growable too. If the current grow heaps run low
on memory it will instruct the grower to allocate a new grow heap. This
reduces the likelyhood of running out of memory with no way to grow to a
minimum. As the growing is done asynchronously it is still possible to
happen, but it is highly unlikely as the grow heap is solely used to
allocate memory in the process of creating new heap areas and it will even
try using normal public memory if the dedicated memory has run out.
* Reduced the dedicated grow heap from 2 to 1MB. As it can now grow itself, it
doesn't need to last so long.
* Extract heap creation into it's own function that does area creation and heap
attach and use this function for growing normal and grow heaps.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26009 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Initialize all static mutexes in the kernel through a MUTEX_INITIALIZER()
and remove the then unneeded mutex_init() for them.
* Remove the workaround for allowing uninitialized mutexes on kernel startup.
As they are all initialized statically through the MUTEX_INITIALIZER() now
this is not needed anymore.
* An uninitialized mutex will now cause a panic when used to find possibly
remaining cases.
* Remove now unnecessary driver_settings_init_post_sem() function.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25812 a95241bf-73f2-0310-859d-f6bbb57e9c96

Improved the "caches" command:
* List the sum of pages used by a cache tree in the line printed for the
root cache.
* Also print the amount of committed memory per cache (and the sum for
the tree), and allow sorting the list by it ("-c" switch).
* Added usage text.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25675 a95241bf-73f2-0310-859d-f6bbb57e9c96

Pimped up the "caches" command. Now it prints the caches in trees with
additional info (offset, size, used pages, areas), sorting the trees
by used pages.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25633 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implemented unmapping of partial areas (mmap()/munmap()). Review
welcome.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25629 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added vm_page_write_modified_page_range(), which is similar to
vm_page_write_modified_pages(), save that it only writes pages in the
given range.
* Added vm_page_schedule_write_page_range() which schedules all modified
pages in the given cache's range for writing by the page writer.
* Added _kern_sync_memory() syscall and the msync() POSIX function.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25620 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Jan Klötzke (with additional TODO comments):
* Add a "fault_callback" to the thread structure which is called when a
unhandled page fault happens in user space. A SIGSEGV will only be sent
if the callback returns "true".


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25609 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fixed build with tracing turned on.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25483 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added new private area protection flag B_KERNEL_AREA, which prevents all
changes to the area (delete, resize, clone) from userland.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25450 a95241bf-73f2-0310-859d-f6bbb57e9c96

Also align the given size to pages when unmapping memory. Fixes munmap()
for non-aligned sizes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25399 a95241bf-73f2-0310-859d-f6bbb57e9c96

Replaced the sAvailableMemoryLock benaphore with a mutex.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25379 a95241bf-73f2-0310-859d-f6bbb57e9c96

First part of the vm86 work by Jan Klötzke:
* Allow userland teams to create areas below 1 MB when requested specifically.
* Note, this is a temporary solution - see the comments in the code.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25358 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Removed old mutex implementation and renamed cutex to mutex.
* Trivial adjustments of code using mutexes. Mostly removing the
mutex_init() return value check.
* Added mutex_lock_threads_locked(), which is called with the threads
spinlock being held. The spinlock is released while waiting, of
course. This function is useful in cases where the existence of the
mutex object is ensured by holding the threads spinlock.
* Changed the two instances in the VFS code where an IO context of
another team needs to be locked to use mutex_lock_threads_locked().
Before it required a semaphore-based mutex implementation.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25283 a95241bf-73f2-0310-859d-f6bbb57e9c96

Replaced the vm_cache mutex by a cutex. This should save quite a few
semaphores.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25277 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Detemplatized ConditionVariable{Entry}. Merged them with their
respective Private* base class.
* Changed sigwait() and sigsuspend() to use thread_block() instead of a
condition variable.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25100 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added <sys/mman.h> header. It declares only mmap() and munmap() yet
and defines the macros needed by them.
* Renamed syscall sys_vm_map_file() to _kern_map_file() and changed the
path to an FD parameter. Changed vm_map_file() accordingly and
adjusted the kernel ELF loader and the runtime loader.
* Added syscall _kern_unmap_memory().
* Added bool unmapAddressRange parameter to vm_create_anonymous_area()
and map_backing_store(). If true and the address specification is
B_EXACT_ADDRESS, all areas in the specified address range will be
deleted (unless an area is covered only partially).
* Introduced B_SHARED_AREA flag, which is set on areas that have been
created by {vm,_user}_map_file() with REGION_NO_PRIVATE_MAP. When
fork()ing those areas won't be copied CoW, but rather be cloned. This
is needed for mmap() MAP_SHARED.
* {vm,_user}_map_file() also accept an FD argument < 0, in which case an
anonymous area is created.
* Implemented mmap() and munmap(). Currently there's the restriction
that we can't partially unmap areas. Otherwise the functions should be
rather compliant. We also support the non-POSIX extension
MAP_ANONYMOUS.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24964 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added TODO regarding potential deadlock.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24820 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Renamed vm_get_available_memory() to vm_available_memory() to fit better
into our usual naming scheme.
* Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24745 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added new KDL command "string" that dumps a string given a pointer.
* Use parse_expression() where appropriate.
* Removed extraneous white space.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24593 a95241bf-73f2-0310-859d-f6bbb57e9c96

Applied patch by Rene Gollent:
* Add a cached_pages field to the system_info structure, and change the
meaning of the used_pages field to not include cached pages.
* Provide the needed info using the new calls vm_get_available_memory(),
and vm_page_num_available_pages().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24571 a95241bf-73f2-0310-859d-f6bbb57e9c96

Leave tracing disabled by default though.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24497 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fix broken TRACE statement.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24496 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Fixed warnings, mostly due to NULL changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24487 a95241bf-73f2-0310-859d-f6bbb57e9c96

Naive implementation of transfer_area(). It follows the suggested sematics
of the resolved ToDo, but could probably be made more efficient. Instead of
transfering the area, the area is cloned into the target teams' address space
and the original is deleted. This generates a new area_id for the transfered
area (as suggested by the ToDo). Updated syscall prototypes according to the
status_t to area_id return type change.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24320 a95241bf-73f2-0310-859d-f6bbb57e9c96

Complete rework of the heap implementation. Freelists are now part of the pages
and pages are now kept in lists as well. This allows to return free pages once
a bin does not need them anymore. Partially filled pages are kept in a sorted
linked list so that allocation will always happen on the fullest page - this
favours having full pages and makes it more likely lightly used pages will get
completely empty so they can be returned. Generally this now goes more in the
direction of a slab allocator.
The allocation logic has been extracted, so a heap is now simply attachable to
a region of memory. This allows for multiple heaps and for dynamic growing. In
case the allocator runs out of free pages, an asynchronous growing thread is
notified to create a new area and attach a new heap to it.
By default the kernel heap is now set to 16MB and grows by 8MB each time all
heaps run full.
This should solve quite a few issues, like certain bins just claiming all pages
so that even if there is free space nothing can be allocated. Also it obviously
does aways with filling the heap page by page until it overgrows.
I think this is now a well performing and scalable allocator we can live with
for quite some time. It is well tested under emulation and real hardware and
performs as expected. If problems come up there is an extensive sanity checker
that can be enabled by PARANOID_VALIDATION that covers most aspects of the
allocator. For normal operation this is not necessary though and is therefore
disabled by default.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23939 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added a boolean "force" parameter to thread_yield(). When true, the
function has the old behavior. When false, it just calls the scheduler
without any priority adjustment or other stuff.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23906 a95241bf-73f2-0310-859d-f6bbb57e9c96

Limit the number of stack frames we print. Infinite recursions or, even worse,
cyclic stack frames would be seriously annoying.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23712 a95241bf-73f2-0310-859d-f6bbb57e9c96

* vm_create_anonymous_area() now accepts B_ANY_KERNEL_BLOCK_ADDRESS.
* As a temporary work-around for the current slab allocator's area usage,
I added the CACHE_LARGE_SLAB flag, which will force the allocator to
use larger areas.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23564 a95241bf-73f2-0310-859d-f6bbb57e9c96

* B_ANY_KERNEL_BLOCK_ADDRESS now aligns the memory on the next power of two
value greater or equal its size (actually untested, but at least Haiku
still boots with these changes :-)).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23563 a95241bf-73f2-0310-859d-f6bbb57e9c96

Made Haiku behave better when you have more memory:
* with 1 GB or more, the semaphore limit is now 131072 instead of 65536.
* double the heap when there is 1 GB or more (64 MB).
* the low memory handler now also watches semaphore usage; in the end,
we need a low resource handler, not a low memory handler.
* create_sem_etc() no longer calls vfs_free_unused_vnodes() directly as
this could actually deadlock (at least because the address space is a
R/W lock, not a recursive lock).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23538 a95241bf-73f2-0310-859d-f6bbb57e9c96

Make the initial size of the slab depend on the CPU count. This avoids running out of initial space with more than two CPUs. I haven't fully tracked down the usage of this space, probably it is used to allocate some per CPU construct.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23115 a95241bf-73f2-0310-859d-f6bbb57e9c96