la57 kernel support is required. we simply add a 5th level and enable the cr4
feature. the safemode option "256tb_memory_limit" is named after the 4gb one,
but the current support is limited to 512GB as before (this can be later extended).
Change-Id: I922774473c4a6112a0e4ff74162285ad58aa53af
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3552
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
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>
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>
There is no good reason to put them in a private header.
No functional change (but drivers now have access
to these constants.)
Change-Id: I7ac00a120ab44fbc110bc858dfd87d69d0061135
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2294
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: John Scipione <jscipione@gmail.com>
- Factor in types changes (introduction of intptr_t)
- Align JamFiles syntax with in progress architectures (arm/sparc)
- Xorriso doesn't support much of the mkisofs options (anymore ?)
- (After a correct bootstrap) one should be able to build @minimum-raw and haiku-boot-cd again
Change-Id: I4f779ad8f2210389fa9b7f7c0a98c3652a64c257
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1983
Reviewed-by: François Revol <revol@free.fr>
This makes ARM64 target compile more files. This patch is one of
series of patches to support new architecture, as fixes in many
places are required just to compile the code.
Signed-off-by: Jaroslaw Pelczar <jarek@jpelczar.com>
Change-Id: Ia060612733cd3a0fcb781fec449da164ed635b8e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1807
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
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.)
Consider this scenario:
* A userland thread puts its ID into some structure so that it
can be woken up later, sets its wait_status to initiate the
begin of the wait, and then calls _user_block_thread.
* A second thread finishes whatever task the first thread
intended to wait for, reads the ID almost immediately
after it was written, and calls _user_unblock_thread.
* _user_unblock_thread was called so soon that the first
thread is not yet blocked on the _user_block_thread block,
but is instead blocked on e.g. the thread's main mutex.
* The first thread's thread_block() call returns B_OK.
As in this example it was inside mutex_lock, it thinks
that it now owns the mutex.
* But it doesn't own the mutex, and so (until yesterday)
all sorts of mayhem and then a random crash occurs, or
(after yesterday) an assert-failure is tripped that
the thread does not own the mutex it expected to.
The above scenario is not a hypothetical, but is in fact the
exact scenario behind the strange panics in #15211.
The solution is to only have _user_unblock_thread actually
unblock threads that were blocked by _user_block_thread,
so I've introduced a new BLOCK_TYPE to differentiate these.
While I'm at it, remove the BLOCK_TYPE_USER_BASE, which was
never used (and now never will be.) If we want to differentiate
different consumers of _user_block_thread for debugging
purposes, we should use the currently-unused "object"
argument to thread_block, instead of cluttering the
relatively-clean block type debugging code with special
types.
One final note: The race condition which was the case of
this bug does not, in fact, imply a deadlock on the part
of the rw_lock here. The wait_status is protected by the
thread's mutex, which is acquired by both _user_block_thread
and _user_unblock_thread, and so if _user_unblock_thread
succeeds faster than _user_block_thread can initiate
the block, it will just see that wait_status is already
<= 0 and return immediately.
Fixes#15211.
add-ons" is set.
Confirmed to fix#14361. It is finally possible to un-brick an install
with a bad system library in non-packaged without having to use another
install to do so.
Change-Id: Iafea7821f02cb34e77c766b1f97d1c19206b1081
Reviewed-on: https://review.haiku-os.org/c/1452
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Kernel is 64 bit, and we won't need a 32bit load base.
Change-Id: I729bab01c8f71083002db061e153b0e5052b9a1c
Reviewed-on: https://review.haiku-os.org/c/1326
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Change-Id: Ia2a86d8814d06950ea2d2d19d966c642d26f81d6
Reviewed-on: https://review.haiku-os.org/c/1302
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Add various stubs to fix undefined references. No implementation for
anything yet.
Change-Id: I2d398bc2369d099e3a35f0713058d6a5edc6801d
Reviewed-on: https://review.haiku-os.org/c/1138
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Add empty implementation of timer, elf, vm, debugger support, to let the
kernel link.
Also add the kernel linker script.
Change-Id: If0795fa6554aea3df1ee544c25cc4832634ffd78
Reviewed-on: https://review.haiku-os.org/c/1108
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Previous commit adding these was merged very quickly, so here's one
more...
Change-Id: I23c424db7631db1f0ec48e2d0ae47c8409ae6af2
Reviewed-on: https://review.haiku-os.org/c/1088
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Gets the stage0 bootstrap to run.
Imlementation is probably nonsense at this point.
Change-Id: I10876efbb54314b864c0ad951152757cdb2fd366
Reviewed-on: https://review.haiku-os.org/c/1061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It is only used as an argument to _kern_load_image directly, not to
any of the load_image functions in image.h, so it belongs in a syscall-
specific header like other such constants.
No functional change intended.
This reverts commit c558f9c8fe.
This reverts commit 44f24718b1.
This reverts commit a69cb33030.
This reverts commit 951182620e.
There have been multiple reports that these changes break mounting NTFS partitions
(on all systems, see #14204), and shutting down (on certain systems, see #12405.)
Until they can be fixed, they are being backed out.
* in load_image_internal(), elf32_load_user_image checks whether the binary
format requires the compatibility mode.
* we then set up the flag THREAD_FLAGS_COMPAT_MODE and the address space size.
* the compatibility mode runtime_loader is hardcoded with x86/runtime_loader.
* if needed, the 64-bit flat_args structure is converted in-place to its 32-bit
layout.
* a 32-bit flat_args isn't handled yet (a 32-bit team execs a 64-bit binary).
Change-Id: Ia6a066bde8d1774d85de29b48dc500e27ae9668f
* x86 uses a commpage with 32-bit addresses, incompatible with the one used for
x86_64. For this reason, a compatibility commpage is needed to support a 32-bit
userland on x86_64.
* define ADDRESS_TYPE as a macro for addr_t (default) or uint32 (for the 32-bit
commpage).
* team_create_thread_start_internal() will use clone_commpage_area() with
KERNEL_USER_DATA_BASE or clone_commpage_compat_area() with
KERNEL_USER32_DATA_BASE, to setup the correct commpage.
* real_time_clock (in compatibility mode) also updates the compatibility
commpage with real time data.
Change-Id: I61605077ce0beabab4439ef54edd1eae26f26fd2
* define ELF32_COMPAT to enable ELF32 macros.
* add a flag ELF_LOAD_USER_IMAGE_TEST_EXECUTABLE to only check the format.
It will be used by load_image_internal() to check which mode to use when
loading an image.
* in arch_elf_relocate_rel(), switch to elf_addr instead of addr_t, which
would be the wrong size for elf32 on x86_64.
* the ELF compat loader reuses the relevant parts of elf.cpp and arch_elf.cpp,
excluding for instance load_kernel_add_on() or dump functions.
Change-Id: Ifa47334e5adefd45405a823a3accbd12eee5b116
* also adjust BOOT_GDT_SEGMENT_COUNT for x86, the definition is used by the
boot loader.
* add some 32-bit definitions.
* add a UserTLSDescriptor class, this will be used by 32-bit threads.
Change-Id: I5b1d978969a1ce97091a16c9ec2ad7c0ca831656
SMAP will generated page faults when the kernel tries to access user pages unless overriden.
If SMAP is enabled, the override instructions are written where needed in memory with
binary "altcodepatches".
Support is enabled by default, might be disabled per safemode setting.
Change-Id: Ife26cd765056aeaf65b2ffa3cadd0dcf4e273a96
* Fixes problems with setting the partition name after uninitializing
a partition in DriveSetup. Previously, UninitializeJob() was
followed by SetStringJob(), but the kernel was updating the
change counter for the parent partition when uninitializing a
partition, leading to SetStringJob() having an incorrect change
counter for the parent partition. Now the parent change counter
will be correct when SetStringJob() runs.
* Add function core_dump_write_core_file(). It writes a core file for
the current thread's team. The file format is similar to that of
other OSs (i.e. ELF with PT_LOAD segments and a PT_NOTE segment), but
most of the notes are Haiku specific (infos for team, areas, images,
threads). More data will probably need to be added.
* Add team flag TEAM_FLAG_DUMP_CORE, thread flag
THREAD_FLAGS_TRAP_FOR_CORE_DUMP, and Team property coreDumpCondition,
a condition variable available while a core dump is progress. A
thread that finds its flag THREAD_FLAGS_TRAP_FOR_CORE_DUMP set before
exiting the kernel to userland calls core_dump_trap_thread(), which
blocks on the condition variable until the core dump has finished. We
need the team's threads to stop so we can get their CPU state (and
have a generally unchanging team state while writing the core file).
* Add user debugger message B_DEBUG_WRITE_CORE_FILE. It causes
core_dump_write_core_file() to be called for the team.
* Dumping core as an immediate effect of a terminal signal has not been
implemented yet, but that should be fairly straight forward.
Reduce duplication of code by
* Removing from elf_common.h definitions available in os/kernel/elf.h
* Deleting elf32.h and elf64.h
* Renaming elf_common.h to elf_private.h
* Updating source to build using public and private ELF header files
together
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
