Various projects, both commercial and OSS, began to use inclusive
terminology. There is no reason to not do it.
In Haiku, bootloader uses Blacklist, which is recommended to replace
with Denylist or Blocklist. I think Blocklist is appropriate here,
since it's a list used to block offending driver at boot.
Some strings remain unchanged for compatibility with previous naming,
but this change prepares for later removal of these (once everyone has
updated their kernel and bootloader).
Change-Id: Id9105ff5e9fcb866000355089b5ef97bf63ee854
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3145
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
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>
* otherwise the signal to be handled might be blocked. fixes#15193
* also remove automatic syscall restart on _kern_select, to match Linux and
BSDs behavior: this fixes parallel build with newer gnu make, which happens
to use pselect.
* also remove automatic syscall restart on _kern_poll.
from https://man7.org/linux/man-pages/man7/signal.7.html
"The following interfaces are never restarted after being
interrupted by a signal handler, regardless of the use of
SA_RESTART; they always fail with the error EINTR when
interrupted by a signal handler: ...
select(2), and pselect(2)."
from https://notes.shichao.io/unp/ch6/
"Berkeley-derived kernels never automatically restart select."
Change-Id: I3e9488f60c966b38d427f992f06e6e2217d4adc5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3636
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
* otherwise the signal to be handled might be blocked. fixes#15193
* also remove automatic syscall restart on _kern_select, to match Linux and
BSDs behavior: this fixes parallel build with newer gnu make, which happens
to use pselect.
* also remove automatic syscall restart on _kern_poll.
from https://man7.org/linux/man-pages/man7/signal.7.html
"The following interfaces are never restarted after being
interrupted by a signal handler, regardless of the use of
SA_RESTART; they always fail with the error EINTR when
interrupted by a signal handler: ...
select(2), and pselect(2)."
from https://notes.shichao.io/unp/ch6/
"Berkeley-derived kernels never automatically restart select."
Change-Id: I7f86d221eae1ad93d8a308a75581d2c30a369c9e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3627
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
On sparc, the minimal page size we can use is 8K. Since B_PAGE_SIZE and
PAGESIZE defines were hardcoded to 4K, this resulted in a lot of
confusion in all code trying to manipulate pages.
- Remove cpu.h from headers/private/kernel/arch/*. It dates back from
NewOS and was not used anymore since our kernel uses B_PAGE_SIZE
(PAGE_SIZE was the only thing defined in this header).
- Add posix/arch/*/limits.h with the arch specific page size and include
it from the main limits.h.
- Adjust bios_ia32/debug.cpp which was the only place using the
PAGE_SIZE constant from the deleted headers.
- Change OS.h to define B_PAGE_SIZE to be the same as POSIX PAGESIZE.
- Define PAGESIZE in the build header if the host OS doesn't.
Change-Id: I8c3732cf952ea3c2f088aa16d216678fbf198b96
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3558
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Mostly the same as PowerPC, using OpenFirmware.
Change-Id: I197cc181e92da92c272ee9cfa20c8ad2d2c63d41
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3579
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The manually written code was all wrong (missing branch delay slots,
wrong type of return instruction used, probably more bugs). Use the same
approach as x86 to have inline functions instead, which is much better
for performance and simpler to write.
Change-Id: Iac0fc814c15311658f983da58ac7f9d3edd75b81
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3595
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The definition in SupportDefs.h using gcc builtins is sufficient. No
need for a custom one. The same approach is used on x86 with gcc8
already, but other platforms had not been adjusted to use it.
Change-Id: I3973ff723a31f90cc8d19ac098eb1e85d471d610
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3594
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The sparc ABI reserves the g7 register for this.
Change-Id: I93b81ecef72cde859972ef7b7f6b9991d35f9f29
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3583
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It was bumped for bios and efi from previously very low values, but
other architectures did not follow.
Change-Id: I6ce92e2cdb0261d4d0637753e77d555d407073fc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3575
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Makes our UEFI bootloader somewhat FDT/DTB aware on all
architectures.
* Will report when an FDT is found, and provide it to kernels
that want it.
Change-Id: I90324fc0579a9c835e60568fa9b654c2df0aba27
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3543
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
the preallocate syscall will call the preallocate filesystem hook, if available.
fix#6285
Change-Id: Ifff4595548610c8e009d4e5ffb64c37e0884e62d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3382
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Currently used by fixup_next_boot_floppy.
Change-Id: I47c10657b5280f00e470a3171ad11744859ce76c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3310
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
when the cpufreq module is loaded, we let the scheduler update its policy.
Improve assert report
CoreEntry::GetLoad() could return more than kMaxLoad.
Change-Id: I127f9b3e8062b5996872aae30b4021b9904fa179
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3216
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
implement on x86 with APERFMPERF.
Change-Id: Ia484854c76dee76c5447983de15800a25d791d39
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3213
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
to call a function on the target cpu. Early mechanism not available.
Change-Id: I9d049e618c319c59729d1ab53fb313b748f82315
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3212
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
When a thread is created, it is expected that some other thread (usually the
creating thread) will want to make sure it completes. This is done using the
pthread_join() or wait_for_thread() calls.
It is possible that threads end before another thread waits for its completion.
That's why there is a dead thread list for each team, which holds thread ids
and their exit status so that a call to pthread_join() or wait_for_thread() in
the future can complete succesfully.
The dead thread list was limited to 32 threads per team. If there would be
more, the oldest thread would be kicked off. This could cause issues in
situations where a team would create more than 32 threads, and would start
waiting for their result after they have finished. Some of the calls would fail
because the threads would no longer be in the dead list.
This specifically caused problems for cargo (the Rust package manager), which
could depending on the number of dependencies, could create more than 32
threads. See: https://github.com/nielx/rust/issues/3
This change removes the limit of dead threads within a team. Note that there is
a risk that a badly written program that does not detach or joins its threads
can make this an endless list, but the impact is relatively small (dead threads
only occupy a bit of kernel memory).
Change-Id: I0135dd54e10ee48a529f23228d21237d4f1a74e2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3178
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
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>
Change-Id: Id050fad59ede444f2eab7eca681c6ec44612aaf9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3160
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: François Revol <revol@free.fr>
This enables generation of exceptions that are due to uncorrected
hardware errors. The exception handlers were already in place and will
now actually trigger kernel panics.
Note that this is the simplest form of MCE "handling" and does not add
anything of the broader machine check architecture (MCA) that also allow
reporting of corrected errors. As MCEs are generally hard to decode due
to their hardware specifity, this merely makes such problems more
obvious.
Might help to discern hardware issues in cases that would otherwise just
triple fault and cause a reboot.
Change-Id: I9e3a2640458f7c562066478d0ca90e3a46c3a325
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3155
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
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>
* Migrate some platform agnostic architecture code into
boot/arch from efi/arch. This helps to avoid conflicts
between kernel and boot sources as well.
* Conflicts between arch_cpu in efi and kernel code means
bootcode really should *never* directly use kernel arch
headers. (other platforms don't, which is why they don't
have this same issue)
* We carefully thread any needed kernel headers (namely
assembly helper macros) into the bootloader headers without
mixing in the whole conflicting kernel/arch headers.
* ARM now properly get its cpu init code called, and we
progress further into the EFI bootloader.
Change-Id: If67ec9758b5ce68563ebd9eb45d5196401911c67
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2975
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
None of these were used; they were all imported with the original
root Haiku commit, and they are totally unrelated to PulkoMandy's
new SPARC work. Plus, they were also under a BSD Advertising Clause
license.
xsave or xsavec are supported.
breaks vregs compatibility.
change the thread structure object cache alignment to 64
the xsave fpu_state size isn't defined, it is for instance 832 here, thus I picked 1024.
Change-Id: I4a0cab0bc42c1d37f24dcafb8259f8ff24a330d2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2849
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
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>
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>
They return the left and right most nodes of the entire tree, i.e.
starting from the root node.
Change-Id: I651a9db6d12308aef4c2ed71484958428e58c9bc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2838
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The code in the Resize and Rebase methods was identical except for the
iterator.
Change-Id: I9f6b3c2c09af0c26778215bd627fed030c4d46f1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2835
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This allows switching from another recursive_lock, mutex or read-locked
rw_lock analogous to the switching possibilities already in mutex.
With this, recursive_locks can be used in more complex situations where
previously only mutexes would work.
Also add debugger command to dump a recursive_lock.
Change-Id: Ibeeae1b42c543d925dec61a3b257e1f3df7f8934
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2834
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The memory map may be unordered and include overlapping ranges. To make
sure that nothing gets included as usable that should actually be
excluded, first scan for all usable ranges and add them, then remove
anything unusable from these ranges again.
To calculate the amount of unusable memory, count the total after the
first pass and then subtract the total after the second. This way, only
unusable ranges that actually overlap physical memory (and therefore
reduce the amount of usable memory) get excluded.
Note that the explicit ignore of the ACPI reclaim memory is subsumed by
the above. We still don't want to add this region to the usable memory
map, as that would allow the kernel to allocate pages into that region,
possibly corrupting ACPI tables before they were used. We also don't
want to add it as an allocated range, as it is not guaranteed that ACPI
is done with the tables before the unused bootloader ranges are freed in
the kernel.
Also add the missing unusable memory amount from ignoring the first MiB
of memory in the EFI loader.
May fix#16056 although it is not certain that graphics memory ranges
are actually included in the memory map.
Change-Id: Ie7991d2c4dcd988edac2995b3a7efc509fa0f4a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2814
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I forgot to change MUTEX_INITIALIZER following removal of the
unused field.
Change-Id: I011c023ae00bb4576c8bcecf83546892fef3a77e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2719
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
As far as I can tell, there is no reason to ignore unlocks, ever;
if no threads are waiting, then mutex_unlock() will act appropriately.
So all we need to do is increment the lock's count here,
as we are relinquishing our request for locking.
On the other hand, if we did not find our structure in the lock,
that means we own the lock; so to return with an error from here
without changing the count would result in a deadlock, as the lock
would then be ours, despite our error code implying otherwise.
Additionally, take care of part of the case where we have woken up
by mutex_destroy(), by setting thread to NULL and checking for it
in that case. There is still a race here, however.
May fix#16044, as it appears there is a case where ACPICA
calls this with a timeout of 0 (we should make this be
a mutex_trylock, anyway.)
Change-Id: I98215df218514c70ac1922bc3a6f10e01087e44b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2716
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
