Change-Id: Idf7ab6d2aa2b4f8cb4893053b531d2eae7418427
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6608
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Improve the mechanics for JSON parsing by reusing
text buffers during the parse.
Change-Id: I7fb2cae31e6558a5a0c63fd02e1fc6fec4f9e4b3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7106
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
after a0131eaae2884fdced27158c3d34732d1656aca9 mxcsr was possibly also incorrect.
fpu control and mxcsr will be restored with fxrstor/xrstor.
no need to clear pending exceptions on #MF
fix #18656 (and #18624 after reverting).
Change-Id: I7dd5e2e4610747c5b82abd6c67e302d264b4be92
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7104
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* also on x86 for simplicity.
* fixes #18624
* also makes x87 FPU data registers available for x87 floating instructions. EMMS is cheap.
see 25209d81f7
Change-Id: I5c1b399377102f3eb10bc6d7f7247afbaf6d8483
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7089
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
* Declare databridge buffer lengths in LocaleBackend.
* Use strcpy instead of strlcpy when writing to databridge buffers
(this is the first fix for #18598.)
* Check for overflows and error out when they happen.
* Verify that ICU actually knows the timezone in question
and fall back to GMT if it does not (this would also fix that crash.)
Fixes #18598.
While debugging some problems on the HaikuPorts build VMs, mmlr
noticed their clocks had an alarming amount of drift. This prompted
an investigation into TSC calibration mechanisms, and the discovery
that there is a VM-specific one which we did not implement.
This mechanism is more accurate than counting cycles on VMs where
cycles can be "stolen" (the probable cause of the aforementioned
clock drift.)
Tested in VMware (works out of the box) and on QEMU/KVM
(may need TSC frequency specified or a host with invariant TSC.)
Change-Id: I4ccfdb2e4e2621404ec9026e7106c02bf96faf18
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7063
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Solves a few "Unknown connector" errors on newer cards.
* It's just another physical name for DisplayPort
Change-Id: I37a6f1bb1db66279b305bdbce3c200612eac1130
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7042
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>
This undoes fc7864091e2463c0e446f8b3954df4d29e9465af.
It was only ever used by the FreeBSD compatibility layer,
only supported one structure, and created problems with
concurrent builds.
Fixes some PTE concurrent access bugs.
Change-Id: I09ec56861fae389a8a3e228b17a3921b85202c8b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6949
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This switches the application over from using basic
authentication to using token-based authentication in
preparation for later using Open-ID based
authentication flows. The application version is also
bumped in order that the server can detect this version
at some later date in the future when it no longer
supports basic authentication itself.
Change-Id: I7addde1d57503c58d6bcd54908f22f66830c0c59
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6944
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* Replace count_low/count_high with bigtime_t fields plus an int32.
sizeof(spinlock) is now 32 bytes with the debug option enabled.
* Adjust and clean up all spinlock code to use the new fields.
* Fold DEBUG_SPINLOCK_LATENCIES into the new code. Remove the bootloader
option and other flags for it (these were not compiled in by default.)
The new code should be much easier to understand and also more powerful.
However, the information transmitted to userland isn't as useful now;
the KDL command output will have the interesting information.
(Things could be reworked to transmit more interesting information to
userland again if desired, but as this code clearly hadn't been compiled
for many years, as it referred to global spinlocks that have been gone
for a very long time.)
Change-Id: I2cb34078bfdc7604f288a297b6cd1aa7ff9cc512
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6943
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Only the x86 and PPC implementations look like they would have worked,
while the builtin is available and will work across all architectures.
We already use it unconditionally in some parts of libroot.
Change-Id: I2dffb3b2c7cdd605092382b9d649151adb921bb4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6942
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
BSlowContextPopup was mostly a duplicate class of BNavMenu
only on top of BPopUpMenu instead of BMenu. Now, BPopUpNavMenu
just subclasses BNavMenu and adds the few features of BPopUpMenu
neccessary.
Drag-and-drop of files using the pop-up nav menu seems to still work fine.
Change-Id: Ic1f49c5bed60fff7a3076a22f74aebc6eba51d57
on x86_64 implemented with rdtscp or rdpid, generically with a syscall.
Change-Id: I8f776848bf35575abec8a8c612c4a25d8550daea
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6866
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Implemented `UnixBufferQueue::SetCapacity` so that `setsockopt`
with `SO_RCVBUF` will not always return an error.
Change-Id: I2d9be84633f84474fac64b379e9f89ef2751a094
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6816
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* Check fFirst/fLast instead of previous/next. Avoids
list corruption when trying to remove already-removed
elements, instead will cause null-dereference KDL.
* Always set next/previous to NULL even when DEBUG is not
enabled.
This reverts commit c6cd9b51a258017f5cb8d5e494d46f4515705a04.
This wound up being unnecessary for the event_queue implementation,
and furthermore is of dubious value in general.
Based on hamishm's original patch from 2015, but heavily modified,
refactored, and reworked.
From the original commit message:
> When an object is deleted, a B_EVENT_INVALID event is delivered,
> and the object is unregistered from the queue.
>
> The special event flag B_EVENT_ONE_SHOT can be passed in when adding
> an object so that the object is automatically unregistered when an
> event is delivered.
Modifications to the original change include:
* Removed the public interface (syscalls remain private for the moment)
* Event list queueing/dequeueing almost entirely rewritten, including:
- Clear events field when dequeueing.
- Have B_EVENT_QUEUED actually indicate whether the event has been
appended to the linked list (or not), based around lock state.
The previous logic was prone to races and double-insertions.
- "Modify" is now just "Deselect + Select" performed at once;
previously it could cause use-after-frees.
- Unlock for deselect only once at the end of dequeue.
- Handle INVALID events still in the queue upon destruction,
fixing memory leaks.
* Deduplified code with wait_for_objects.
* Use of C++ virtual dispatch instead of C-style enum + function calls,
and BReferenceable plus destructors for teardown.
* Removed select/modify/delete flags. Select/Modify are now the same
operation on the syscall interface, and "Delete" is done when 0
is passed for "events". Additionally, the events selected can be fetched
by passing -1 for "events".
* Implemented level-triggered mode.
* Use of BStackOrHeapArray and other convenience routines in syscalls.
Change-Id: I1d2f094fd981c95215a59adbc087523c7bbbe40b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6745
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
ASID allocation is not supported yet, so always use ASID 0 for user pages for now.
Change-Id: I021e77dae692c22984bc625dd0588362bece45b7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6698
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
gcc 13 is confused by the custom bitset implementation, so use the C++
standard one instead.
However, this results in including the C++ <string> header in kernel
code. This doesn't work for gcc2, because of two problems:
- That header includes a declaration of atomic_add that doesn't match
the one in SupportsDefs.h (which can in some cases replace the function
with a #define for an inline version). Adjust the header to use the
be a problem because it creates a risk of circular inclusions.
Standard C++ headers shouldn't depend on BeAPI ones.
- It also leads to the inclusion of iostream which defined lock and
unlock functions in the global namespace. We don't want these, and they
are not part of the C++ standard, so just remove them.
Ideally we could use std::hash for the GetHashCode implementation, but
that doesn't work because it depends on an helper function that's in
libstdc++, and we can't link that from kernel add-ons.
Change-Id: Iee07280beb4dddf7a9b6160e37f3b816e4de89ae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6663
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Previously this just turned the rw_lock into the equivalent of a
recursive_lock, which meant that reader vs. writer assertions
were of no use.
Now, we have a per-thread static array which stores the held read
locks, allowing ASSERT_READ_LOCKED_RW_LOCK to work properly,
and allowing multiple readers to be active at a time.
This probably should still remain disabled even on nightly builds,
but at least it's much more useful as a debugging tool than it was
beforehand.
Change-Id: I386b2bc2ada8df42f4ab11a05563ef22af58e77f
GCC 13 is more strict about what C++ features are available in a freestanding
(= build without standard library) build. The `stdlib.h` and `math.h` headers
are redefined as part of libstdc++. If the object is built as freestanding, it
should be assumed that none of the standard library functions are available.
The solution in Haiku has been to add part of the standard library into the
kernel shared object. The method of exposing them has been to allow the
use of `stdlib.h` and `math.h` in the kernel and in kernel add-ons.
This change allows that approach to continue. What it does, is that it defines
specific headers which will be picked up when a module is built using private
kernel headers. When building for the kernel (or for the boot module), it will
bypass GCC 13's libstdc++ default behaviour of not including the POSIX/platform
header with all the function definitions.
An alternative to be considered for the longer term is to specifically define
the parts of the C/C++ standard library that is available in the kernel in
these headers, or create custom headers when building kernel modules (which is
how Linux approaches it).
Change-Id: Icab4614f642219fa77732b02401570708ee9a963
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6645
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
- 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>
This requires the introduction of the flag B_USER_MUTEX_SHARED, and then
actually using the SHARED flags in pthread structures to determine when
it should be passed through.
This commit still uses wired memory even for per-team contexts.
That will change in the next commit.
GLTeapot FPS seems about the same.
Change-Id: I749a00dcea1531e113a65299b6d6610f57511fcc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6602
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* Introduce SWDBM flag similarly to the arm64 port
* Reuse TEX[2] for SWDBM flag which should be availble
to be used by the operating system if TEX remap
is enabled.
* Introduce SetAndClearPageTableEntryFlags for updating
accessed and modified flags atomically
* Startup sequence is handled similarly to accessed flag, i.e.
set Modified flag in initially mapped pages in bootloader and early map.
* Once the kernel initialization has progressed enough,
pages are mapped as read-only and modified flag handling is done
in the page fault handler.
Change-Id: I8f761e2c6325d1b91481abd569d5e8befded0761
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6518
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Condition variables are now a pretty common way the kernel blocks threads.
That means the "threads" command was getting difficult to navigate, since
at any given time, a lot of threads could be blocked on "cvar".
Now we try (carefully, because it could fault!) to fetch the first 4
characters of the "type" name and display then. This suffices to
distinguish the most common object block types in the list at a glance
(e.g. "cvar:port" for port reads, the most common.)
Change-Id: I94f4b59fd78b7ebdce913944551a5e98f0ca2e33
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6605
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This allows to see the display in Screen preferences, and know its DPI
and physical size (as much as EDID data can be trusted). This
information could be used to compute the default font size, for example,
so it's important that all drivers provide it whenever possible.
Change-Id: Ic3d04e53cf5fcb24e22d35661d2b364a257947da
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6576
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Suppose the following scenario:
1. Thread A holds a mutex.
2. Thread B goes to acquire the mutex, winds up in kernel waiting.
3. Thread A unlocks; first unsets the LOCKED flag.
As WAITING is set, it calls the kernel; but instead of processing
this immediately, the thread is suspended for any reason (locks,
reschedule, etc.)
4. Thread B hits a timeout, or a signal. It then unblocks in the kernel,
which causes the WAITING flag to be unset.
5. Thread C goes to acquire the lock. It sets the LOCKED flag.
It sees the WAITING flag is not set, so it returns at once,
having successfully acquired the lock.
6. Thread A, suspended back in step 3, resumes.
Now we encounter the problem. Under the previous code, the following
would occur.
7. Thread A sees that no threads are waiting. It thus unsets the LOCKED
flag, and returns from the kernel. Now we have a mutex theoretically
held by thread C but which (illegally) has no LOCKED flag set!
8. Some other thread tries to acquire the lock, and succeeds, for LOCKED
is not set. We now have one lock owned by two separate threads.
That's very bad!
The solution, in this commit, is to (1) switch from using "atomic_or"
to lock mutexes, to using "atomic_test_and_set", and (2) mandate that
_kern_unblock_mutex must be invoked with the mutex already unlocked.
Trying to solve the problem with (2) but without (1) produces other
complications and would overall be more complicated. For instance,
all existing userland code expected that it would set LOCKED, but then
check LOCKED|WAITING. If _kern_mutex_unlock does not unset LOCKED,
then whichever thread sets LOCKED when it was previously unset is
now the mutex's undisputed owner, and if it fails to notice this,
would deadlock.
That could have been solved with extra checks at all lock points, but
then that would mean locks would not be acquired "fairly": it would
be possible for any thread to race with an unlocking thread, and
acquire the lock before the kernel had a chance to wake anyone up.
Given how fast atomics can be, and how slow invoking the kernel is
comparatively, that would probably make our mutexes extremely "unfair."
This would not violate the POSIX specification, but it does seem like
a dangerous choice to make in implementing these APIs.
Linux's "futex" API, which our API bears some similarities to, requires
at least one atomic test-and-set for an uncontended acquisition,
and multiple atomics more for even the simplest case of contended
acquisition. If it works for them, it should work for us, too.
Fixes #18436.
Change-Id: Ib8c28acf04ce03234fe738e41aa0969ca1917540
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6537
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Pages should not be marked as accessed when initially mapping them.
However, there's a short interval during kernel startup when new pages
are mapped but the fault handler is not installed yet.
Therefore, we set Accessed Flag to 1 in early_map.
Once the kernel initialization has progressed enough, we start mapping
new pages with Accessed Flag set to 0.
The chicken and egg problem of initially mapping the vector page is
tackled by preallocating the vector page in the boot loader.
Change-Id: Ie3be4f81812d7a090af57e8c79420598d16182b9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6450
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
