This doesn't get all the filesystems that were missing these checks
(e.g. I didn't adjust the more "WIP" filesystems like XFS and BTRFS)
but it does get most of them.
* Restore logic for excluding app_server side of bitmaps
(though this may not work for server-cloned areas, only
server-allocated ones.)
* Leave TODO in place for media buffers.
* Add all kernel-writable areas of the system (kernel) team
to writable memory, but exclude the block_cache.
Fixes display of kernel memory information in ProcessController's
memory usage menu.
Otherwise it won't be reset at all and we will begin with the
previous thread's FPU state, both for userland and kernel threads.
Also clear the FPU state in x86_return_to_userland, just like
in syscall exit.
Change-Id: Ie46d0e64a680c860c7fbff8dc57116625724eadd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9092
Tested-by: Commit checker robot <[email protected]>
Haiku-Format: Haiku-format Bot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
The XSAVE area can be quite large (1-2KB+), so rather than always
putting it on the kernel stack, just use the arch_thread FPU state.
Change-Id: Ie64c3ea3ca52cd8a4425ae1da69792588a69832a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9090
Reviewed-by: Jérôme Duval <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
This reverts most of c7360f4b02.
Unlike the other floating-point registers, these values are callee-saved
(see "System V Application Binary Interface, AMD64 Architecture
Supplement" section 3.2.1.) So we need to preserve their values and not
reset defaults on context switch.
EMMS, as the previous changes used, does not suffice to clear
exceptions. We could use FNCLEX instead, but we need to reset
x87 state on context switch anyway, so use FNINIT. Do not
reinstate FNCLEX in the exception handler since it will
be executed on context switch anyway.
We also need to ensure a clean initial state, so take care of that
in arch_thread_init.
See also:
* remarks in 396b74228e
* as well as 53e2dc0f85Fixes#19454 and #18624. Doesn't regress #18656 and #19063.
Doesn't seem to affect #19450.
Change-Id: I7179f1ec7304e7aed09ff80f6773e53d5dbdf5f9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9081
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
cache_get_pages locks and unlocks the cache to wait for busy pages,
as well as after it's done, which creates a race where some other
thread may start waiting on a page that we have marked busy. But
as we are about to free those pages, that wait will deadlock.
Just loop through the cache's pages directly, skipping any busy ones
and freeing the others directly.
Fixes a deadlock observed with BFS on a ramdisk.
ssize_t is 64-bit on 64-bit architectures, if we truncate to int
then values above 2GB will be seen as negative and errors instead
of the successes they are.
Seems to fix#16861.
This change will allow the BColumnListView to have
multiple rows added or removed at the same time.
Without this, applications using the BColumnListView
will need to add and remove rows one by one which,
for longer lists with complex columns, is a
performance problem; an example being HaikuDepot.
Note that this change does not amend the formatting
style on the class's source.
Change-Id: I72303c8b069b686251c3a65af7ae45c8884d5637
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9056
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Andrew Lindesay <[email protected]>
The new "-n" parameter waits for the networking to be up.
Code lifted from SoftwareUpdater.
To avoid polling the network status, use start_watching_network().
As this involves messaging, a BApplication is created and a
BMessageRunner is now used to regularly check if threads or
apps have started/ended.
Change-Id: I55b5174dbdbd326d8d40b958ebf966f8fa6718b3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9067
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
* Add FileSystem::EnsureNoCollision to check for a stale node with
the given inode number, and remove it if it exists.
* Call EnsureNoCollision from Inode::CreateObject and
Inode::CreateState to cover creation of directory files and regular
files, respectively.
* Stop using the entry cache. Instead, make use of the driver's
DirectoryCache in the lookup hook.
* Fixes#16924.
When a shared file is deleted, and no clients have the file open, the
server considers the file ID number of the deleted file to be eligible
for reassignment to new files. If the deletion was performed by the
server or by some other client, the Haiku client does't know the file
was deleted, and still may hold a vnode for it. This interferes with
the creation of a new file by the client, when the file ID / ino of
the new file is the same as that of the stale node.
The reason for disabling the entry cache is to give the driver a
chance to check the server for changes in name-to-ino mapping when the
VFS function lookup_dir_entry is called. At least in its current
form, the driver isn't able to deal with outdated entry cache
information. For example, if the Haiku client has added temp.txt to
its entry cache, and then temp.txt is deleted by the server, running
'nano temp.txt' on the client will attempt to open the (non-existent)
file instead of creating it.
Change-Id: Ic3ec21d18c8616fcfeb9234aafb0e647746d23cd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9068
Reviewed-by: waddlesplash <[email protected]>
The menu item starts with: "System resources & caches..." but then it
wrote fCachedMemory before fCommittedMemory.
Swapping them seems more in line with how the rest of the "Memory usage"
menu is presented as well.
Change-Id: I83345f9ae35b405ed854e7a1992b537d31e27d02
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9083
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: humdinger humdinger <[email protected]>
Haiku-Format: Haiku-format Bot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Otherwise there is a race that can occur if the waiting thread is
interrupted (or hasn't slept yet) while the writing thread tries to
unblock it.
Instead, don't call SetNotified again if we unblocked with a status
of B_OK. This can only happen when we were notified by another thread
successfully.
Should help with #19458.
Change-Id: Iad46b26374a01539f8765231d259392c231c786a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9085
Reviewed-by: waddlesplash <[email protected]>
FreeBSD also uses NetBSD's versions (with their own modifications,
however.) So it seems to make sense for us to adopt these, too;
they look to be better tuned than ours were (like handling
non-aligned addresses better, which was a TODO before.)
* Rewrite generic memcpy, with optimizations more like the common memcmp
optimizations.
* Rewrite generic memset, with a proper optimized implementation.
* Name the files "generic_" like other files in the arch generics dirs.
* Always use the generic versions in the bootloader, since it's
complied with special flags.
Put the C++ versions in files with their own names, and
rename the assembly thunks to "commpage_string.S", as it
really just invokes the commpage versions.
The kernel x86 arch_string.S is left alone for the moment
as it will be replaced in the near future anyway.
This is less surprising than having it the other way around.
Adjusted the "MkKeymapHeader1" action on src/servers/input/Jamfile accordingly.
Change-Id: I9fb8f8d7d0cfde493c03755beafbff73222cba93
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9066
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
It's branded as a MediaTek device, but the firmware
copyright is Ralink.
From upstream b96864412700a2a5b5e9aaf5d6513ec062cfc96f.
Includes adaptations to make it compile on Haiku.
This matches the previous behavior (which just used release_sem
or _etc with a count of 1.) The one waiter might delete the object
containing the condition variable on wakeup, so the difference
does matter.
Just find the previous thread and then get the one after it in
the general case. This avoids problems with "unsorted" thread lists
as found in the kernel team or when IDs wrap, with the previous
logic only kept as a fallback if the last-fetched thread
does not exist anymore.
Augustin Cavalier