This is what other architectures do :)
Previously, we only handled signals after system
calls, which could result in a funny sequence of events:
- Thread gets spawned with spawn_thread
- Thread gets resumed with resume_thread, which sends
SIGNAL_CONTINUE_THREAD
- Thread's very first syscall is a read(), which promptly
gets interrupted by SIGNAL_CONTINUE_THREAD and the thread
has no idea why, and doesn't bother to read() again since
it never expected to receive a signal
^^^ PtyReader fell victim to this and Terminal was broken
Change-Id: I32c4c73be21c60cab97add2bb7052dc56a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10608
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
* Ensure some bits in TCR have known values, since the bootloader
might have configured something weird which causes problems for us
(such as configuring a virtual address space that's smaller than
we expect).
* ==NULL check in VMSAv8TranslationMap::UnmapPage was backwards
* Don't receive the number of syscall parameters from userspace. We were
previously reading twice as many arguments as needed when handling
a syscall.
* Save FP/SIMD registers as early as possible, since we can't know when
they might get used
* Reset iframe stack index to 0 upon arch_thread_enter_userspace.
Otherwise, when we exec, we push an iframe and never pop it off
again
Change-Id: I4bc7dcc9303b9103a97226cd7ece4c9b6a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10607
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
It turns out PAGE_ACCESS assertions could be tripped in other cases,
e.g. when resizing a cache while pages were being read in. So,
properly unset ACCESS (and just leave 'busy' set) in the places
where pages are read in, and re-enable the check.
Change-Id: I22ac5c8cb432c87613bb85e82703a0c1aeb55d86
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10627
Reviewed-by: waddlesplash <[email protected]>
Since we unlock the cache at various points in this loop,
we need to periodically recheck the size here, as otherwise
we might try to insert pages past the end.
This amends 4f8eaff87f. Re-tested
using the case described in that commit.
Change-Id: Id65e309f986a9b7f3e701d2b99c4f318a4eefbd3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10626
Reviewed-by: waddlesplash <[email protected]>
This allows the VMCache to remove these pages pending the I/O
completion.
Combined with the following commits, confirmed to fix#18390.
Change-Id: I9630a00d70a9d6ac5b36e6de70475a6032390806
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10591
Reviewed-by: waddlesplash <[email protected]>
Previously, busy-writing pages just stayed in the cache until
I/O finished. This wasn't right, as they should've been unmapped
(and removed) immediately, as a TODO in the PageWriteWrapper noted.
Now they are, and they're moved into a queue on the cache pending
the I/O completing.
This paves the way for fixing #18390.
Change-Id: I51778ba1cfc1d26f34dd44f1ee293381be59937f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8627
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Before, it just used a hardcoded Element::link member. Now,
it uses whatever one is specified based on the template
arguments.
No source compatibility breakage intended.
Change-Id: I62128921766df0b705488eb64402f902334f2ed0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10589
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Haiku-Format: Haiku-format Bot <[email protected]>
This prevents a hang when the kernel tries to remap
its own pages later, during a break-before-make on
what appears to be a page containing jump vectors.
(In the exception frame, ELR points there.)
Change-Id: Idd516c73a7702c2995fe914204d587df6fc713fc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10600
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Sam Roberts <[email protected]>
* Prevent bringing Tracker windows to the foreground when moving the mouse
over them with a button held but not actually dragging a file.
* Fix a regression caused by changing window->Dragging() calls to
IsDragging().
Fixes#19683
Change-Id: Ife55885e72d4682b857baf4103d144f49b765693
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10601
Reviewed-by: nephele nephele <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
- Fix pointer/reference style in btrfs_disk_system.cpp
- Add missing blank line between class definitions in Inode.h
- Remove trailing whitespace in AttributeIterator.h
- Add missing space before inline comment in BTree.cpp
- Add missing space before '{' in ExtentAllocator.cpp
- Fix C-style cast pointer style in Volume.cpp
No functional changes.
Hashtags: gsoc2026
Change-Id: I7922a4736c072691163c05288f142cdaff1dcf9c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10469
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
This fixes a long-standing TODO, and a major inconsistency
that for different caches, "commitment" reserves from different
pools, so any two aren't necessarily convertible.
The new system introduces a virtual method "TakeCommitmentFrom",
which allows the VM's cut_area routine to behave as it did
previously.
They mostly contained descriptions of functions' operations, not
what they're for, so they weren't so useful. I've added some of
the remarks they had (or ones with a similar purpose) inline
as documentation comments, and deleted the rest.
The documentation file hadn't been updated in a very long time,
and referred to locks and paradigms that have long since been
dropped (e.g. sMappingLock was removed in 2010, in
afed2658f4ef3e3df5ff8390d1d7a51b5b897a9e.)
Add a few "protected by" comments in VMArea to clarify things,
but otherwise this document looks entirely obsolete (I went
through all of it.)
EV_ADD implies ENABLE, so this isn't needed, but a lot of applications
try to specify it anyway. So this extends source compatibility.
If in the future we ever implement EV_DISABLE, we can just add a
real definition for it then, and since ADD implies ENABLE existing
applications shouldn't break.
If the source area is now mapped write-combining, so will the
target area.
May fix some problems or slowness that occurred after the
framebuffers refactor commits.
Adds a new sorting mode to the Devices app to allow users to view the
hardware tree sorted by bus connections.
Resolves the TODO: Implement BY_BUS in DevicesView.cpp
Changes:
- Added ORDER_BY_BUS state and kMsgOrderBus constant
- Added Bus option to the orderByPopupMenu
- Implemented alogrithm in RebuildDevicesOutline() to group devices under their CAT_BUS parent
- Added kMsgOrderBus in DevicesApplication to ensure it updates when
selected
Change-Id: I266333e1ced25d231d73a0850e6a8ff3155084c4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10481
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
This allows the guarded heap to be used in a much more targeted way,
if it's suspected specific object_caches have problems.
Enabled by default for KDEBUG. The new safemode/kernel option is
"guarded_heap_for_object_caches". This accepts a comma-separated
list of quoted strings, optionally with * at beginning and/or end
(but not middle.) Examples:
mbufs* # matches caches starting with "mbufs"
*jumbo9* # matches caches containing "jumbo9"
"*jumbo9 chunks","mbufs*" # matches caches ending with "jumbo9 chunks"
# or starting with "mbufs"
This should help with diagnosing #19973, among others, without needing
to compile custom versions of drivers or anything like that.
Unfortunately it is not possible to use this mechanism to selectively
replace parts of the slab malloc. The slab malloc free() relies on
the MemoryManager to figure out what cache an object belongs to, which
doesn't work if objects of some size classes aren't known to the
MemoryManager at all.
Hyper-V needs to be notified when VMBus receive buffer has enough
space for devices supporting this functionality.
Change-Id: Ib2bb0d65bbd8c402d1c73e9cad83d00d644dcf2c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10566
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Picture token written for `BView::DrawPicture` and
`BView::ClipTo[Inverse]Picture` should be zero-based index in
subpictures array, not global app_server BPicture token.
Part of #1133.
Change-Id: I2a544aefb343650e8bad58c5d297f7b9d5d1dbb5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10575
Reviewed-by: waddlesplash <[email protected]>
Before this commit, swap space was committed entirely orthogonally
from memory commitments. This was not handled at all correctly
when cutting areas (the area cutting logic tries to migrate commitments
between caches, but in the case of swapping caches, it didn't,
and couldn't, take the separate fCommittedSwapSize into account.)
Even without that problem, totally separate swap and memory commitments
caused other problems. For instance, suppose a setup with 4GB of RAM
and 4GB of swap. Many caches are created, and all 4GB of swap gets
reserved, but the caches with this swap reserved have no or few pages
in them. Then, all 4GB of RAM gets used up. The page daemon runs, and
looks for things to swap out, but it can't find anything because all
our swappable caches with pages have no swap reservations, so all it
can do is flush out cached pages, which just degrades performance.
Or, consider what would happen if the 4GB of swap was released, but
the 4GB of RAM was still in use, and then the kernel tried to
allocate memory. It would get OOM errors, because none of the
caches have swap commitments and so nothing can be written out.
Under this new system, the specific swap space reservation only happens
just before the page is first written out, so both these cases should
be handled smoothly, and swap should be used in a much more sensible
fashion overall.
This change seems to be more in line with what other OSes do (Windows
Task Manager's "Committed" clearly is RAM+swap, for instance.)
The only potential downside to this change is that swappable caches
may temporarily go over their commitment when reading or writing
out pages to swap, before the page daemon has a chance to come by
and free the page or the swap space. But as that is a temporary state
and should always be resolved by the page daemon, I think it's
probably an acceptable trade-off.
Change-Id: I928f4b4cacbec26ed6315179476eaff1a7f626c8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10305
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This begins paving the way for removal of user access to kernel
address space.
After the previous commits, BDirectWindow and BWindowScreen
still function properly.
Part of #19990.
Change-Id: I8477e43cd517ba67383755a4cb60b00bc117f5d7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10559
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
This will be useful in the case of cloned device caches based
around physical memory, e.g. for framebuffers.
Change-Id: If2b864208e86f436e91379b73c4b866b0bd5e1d7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10558
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Augustin Cavalier