If we were "donated" some commitment (e.g. in copy_on_write_area)
then we don't want to drop it when pre-committing.
Fixes some commitments being too low in forked teams.
Partition::ReadAt() and WriteAt() already do bounds-checking
based on the size, but Size() was returning the underlying FD
size, which might be that of the entire disk, not just this
partition. So, move initialization around a bit, and return
the actual size.
Should fix the bootloader menu displaying the wrong sizes
for boot partitions.
B_USE_HALF_ITEM_SPACING is 6 with a 12pt font, so this increases
the insets slightly. B_USE_BIG_SPACING should be 20, so that
should be the same.
Improves tooltip appearance on HiDPI.
* Set IP_DONTFRAG on all TCP sockets by default.
* Handle receiving B_NET_ERROR_MESSAGE_SIZE, update MaxSegmentSize
appropriately, and trigger retransmit.
Tested and verified as working.
Part of #1073. However this doesn't implement all of what's needed,
only the most basic form of the algorithm (we don't record MTUs
for reuse later for instance, right now we only store routing
information for the LAN, it appears, so we will need somewhere else
to store that.)
Change-Id: I37a24b50db18af908c6f6257c6fb6d72127d2787
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9402
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
* Make IORequestOwner an abstract (ish) class, and move details
to the Scheduler implementations. This will allow other drivers
(like NVMe) to use their own, separate IORequestOwner system.
* Use an object_cache to allocate IOSchedulerSimple::RequestOwners.
Previously, a single block large enough to store one for every
thread at maximum thread count (4096) was allocated, meaning
a few hundred KB per IOScheduler. In the case of low memory,
a fallback IORequestOwner with a thread ID of -1 is used.
Tested with IDE and usb_disk drivers, seems to be working.
As we may have stolen some commitment from the first cache already,
so it will try to increase it here, which won't work if the system
is low on memory.
Should fix#19813.
Than the one used by the area, anyway, so we need to call Rebase
as well as Resize in all cases where the cache is getting reused.
This case happens (rarely) with the bdwgc's gctest, with mprotect VBD
enabled (which still doesn't work reliably, it sometimes crashes userland
or trips asserts in the kernel, but it seems to trip less after this
change.)
Also, let the CacheChainLocker take care of releasing and unlocking
the cache even in the onlyCacheUser case.
* Use the control color, which is what DrawButtonBackground expects
to get the previous appearance.
* Actually use the HEADER_BACKGROUND color from the main view,
which previously was not used at all, allowing applications
to override.
BControlLook::DrawButtonBackground now expects the control color
directly, not the panel background color.
Restores the previous appearance (or one close to it) from before
the control color changes.
sourceCache is now only != NULL if it represents the "cache"'s source.
And "cache" will always be locked when we get to "err2", so we need
to use ReleaseRefAndUnlock.
Should fix#19810.
Creating areas with B_ALREADY_WIRED is done early in the boot process
after VM initialization to create area objects for pages that have
already been allocated and mapped. As such, it should absolutely never
fail, since nearly everything should already have been set up.
But if it does fail, that almost certainly means it either should not
have been called in the first place, or there is some sort of invalid
state. Testing with ARM64 builds, this assertion trips, revealing
that the kernel is actually being placed outside of the declared
KERNEL_BASE+KERNEL_SIZE at present.
They're not needed anymore. The VMTranslationMap method was confusingly
named anyway, as the other Debug* methods are for use in KDL, while
this one required the regular locks and flush mechanisms.
Change-Id: Ic1baf3d786071562d8beaeb768d996cd1d34f9b7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9706
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Compared to the old kernel guarded heap, this new one:
* Uses VMTranslationMap and related APIs directly, rather than
indirectly through the "protection cookie" system. This means
those custom APIs, which nothing else except the guarded heap
used, can now be dropped.
* Does not allocate vm_pages for guard pages, and frees vm_pages
when not in use. This means that DISABLE_MEMORY_REUSE is much
more usable now, as it only does not reuse virtual memory,
allowing for much longer-running systems.
* Uses trees to manage meta chunks. This avoids unbounded growth
of the meta chunk count, especially under DISABLE_MEMORY_REUSE.
* Handles page faults directly and prints information about the
fault address/allocation automatically.
The system still boots and runs fine with this new guarded heap,
including under USE...FOR_OBJECT_CACHE.
Change-Id: If85e5689a47088790287990c881364fcde4cc76d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9705
Reviewed-by: waddlesplash <[email protected]>
lock_memory_etc also acquires the address space read lock.
So, just perform that step first and separately from the loop.
Discovered by the RW_LOCK_DEBUG assertions.
The former must have B_NO_COMMAND_KEY if the shortcut has no command key,
while the latter should simply not have B_COMMAND_KEY.
This mixup meant that modifiers flags without either set were
passed back to BMenuItem, which then used them when calling
RemoveShortcut(), but that method expects B_NO_COMMAND_KEY
to be specified, so the shortcuts weren't really removed,
resulting in use-after-frees.
Fixes#19426 and related issues.
Tested by OscarL and confirmed to be working on at least
one machine, though on others it hangs, so leaving out
of the default builds for now.
This adds an "acpi_processor_id" field to x86 arch_cpu_info,
gleaned from the MADT, so we can match our cpu_ents to ACPI
processor objects. (FreeBSD does a similar mapping, see
their acpi_cpu_probe method.)
Change-Id: Idb5e3c1fc1efaa4256d60ea17dd1824345369687
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9637
Reviewed-by: waddlesplash <[email protected]>
EHCI has more DMA restrictions than XHCI, so if we can't use them,
we just fall back to copying the buffers as before.
Tested in QEMU, system booted successfully. However, it seems that
quite a lot of disk I/O can't use physical buffers here, probably
due to packagefs' use of uncached reads.
Change-Id: I4d35642ee1a8f5ba2531f6658f8cbbef5a7785ac
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9613
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
USB code now goes in a separate static library.
This also paves the way for supporting more busses than PCI
and USB in the compat layer.
Tested with realtekwifi, still works.
* Move ukphy ("unknown phy") code into the compat layer rather
than duplicating it across many drivers.
* Move MIIbus related code to a separate static library.
* Genericize most attach methods that touched the MII bus directly
to not need the code that's now in the static library.
Tested with rtl81xx, still works.
This partially synchronizes to "upstream" commit 3c144bdfe53c61e2589e209d419f28f94ac77151.
Some of the more functional changes and new features I didn't import,
but mostly just the color tinting changes to match the new control colors.
Instead of reusing objects as fast as possible, use two magazines per
CPU, and allocate and free objects from separate magazines, always
exchanging full and empty ones with the depot. Furthermore, reverse
the ordering of objects in full magazines, to get FIFO rather than
LIFO behavior.
sys time on "git status" and "compile HaikuDepot" benchmarks in
a 4-core VM seems increased by about 5% at most (e.g. 8.2s -> 8.6s.)
This may help with further catching use-after-free and other like
problems, so it seems worth it to leave enabled on KDEBUG.
B_FILE_ERROR == EBADF == "Bad file descriptor". It's used
when there's no valid file descriptor, or when attempting
a read or write operation on a file descriptor not opened
with that mode. All other places should use B_IO_ERROR or
some other like value, instead.
The tty_notify_select_event() at the end of tty_close_cookie()
checked if the other_tty's open_count was > 0 before notifying.
But in the case where the master is closing all children,
it will drop to 0 and leave things still in the select pool.
So we should notify unconditionally here.
Additionally, use B_SELECT_DISCONNECTED (i.e. POLLHUP). This matches
what Linux seems to do.
Fixes#19714.
This should make use-after-frees more likely to be caught by the
standard paranoia facilities (and make them less likely to be
exploitable as memory will take longer to be reused.)
Otherwise, the only place we resize the table is Remove(), and if
that doesn't get called (because no files are being deleted) then
we will rarely, if ever, resize the table, leading to performance
issues.
Fixes a performance regression easily seen by running "grep -R".
This allows us to avoid extra calculations and read barriers
in spin() from system_time(), and it should be easier to detect
as an "idle loop" if emulators want to do that.
In 5b14757a30 (2005), a change was made
to have root nodes be owned by filesystems, rather than
by the VFS (as BeOS did.) However, later on,
in fe5928847a (2011),
the adding of covered vnodes broke that.
As put_vnode's error was silently ignored, this went unnoticed
until this week, when the new asserts started firing.
So, to fix this, increment the reference count of the root when
setting its covering vnode, and handle the root specially.
Assert in ~fs_mount that there are no vnodes left; if the
filesystem failed to free it, this assert will trip.
Fixes the new assert seen in #19642.
Many of the callers of this method didn't initialize
the length parameter properly, which led to uninitialized
memory being used as part of the min() calculation, which
caused all sorts of problems.
Now we don't require them to pass in anything, and use the
constant directly.
Fixes#19252.
* panic under KDEBUG if the node does not exist.
* panic always if the node reference count was 0.
We don't handle 0 -> 1 transitions here, and it doesn't make
sense to acquire "another" reference to a node you
haven't referenced.
Would have caught the ext2 use-after-free fixed in an earlier
commit.
Setting the length of a frame outside the current xfer frame count
(but less than the maximum count) is allowed on FreeBSD.
Fixes a KDL encountered with the FreeBSD version of the ASIX
USB ethernet driver.
XHCI's DMA requirements are very relaxed, we can set TRB addresses
without having to align everything to page boundaries, it seems.
The only restriction is that some controllers may not support
64-bit DMA, but we only do 32-bit at present anyway, so just
reject transfers with non-32-bit addresses and add a constraint
in the USB disk driver.
Tested with QEMU, seems to be working.
Change-Id: I6a2b1689ce1a718aaba7622addbd8ab2fc57ca75
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9612
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Unlike NVMe, USB disks are often slow, so we want the benefits
of the real I/O scheduler and asynchronous operations.
The downside is that all USB requests will be submitted as
physical, rather than virtual as some are at present. This
means that in some cases the bouncing will cause double-copying
unnecessarily. (However, it should be possible to avoid that
in all cases for XHCI at least.)
Change-Id: I7d827da7b5769d4ba988ae6cb3964e6c2190e56a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9611
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Otherwise, if we are locking memory that's mapped from this
same usb_disk device, we'll cause a double lock.
Should fix#19715. But really, we should probably be using
an IOScheduler here, so the next commit will implement that.
Change-Id: Icd62955338ef66444ec6a14e0310f60061456d8f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9610
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
These instructions are only available on more recent CPUs (MWAITX
on AMD since around 2015 or so, TPAUSE on Intel since around 2020.)
They allow idly waiting on the TSC even when interrupts are
disabled.
Most hypervisors do not have these available (KVM does provide
them, though not on all configurations), but on bare metal this
should make a nice difference to KDL power consumption: I tested
with a Ryzen 3700X, according to my UPS (so including monitor
and peripherals) the system used ~106 W at idle, 160 W in KDL
before this patch, and 125 W in KDL after it.
Change-Id: Id7a22ecd33f3fc005b2c312f945dc3cd364e96fa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9604
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
The idea is to add a facility that will use less CPU than
the loops we currently use. The default implementation just
calls spin(), which is rdtsc+pause. This already may save
some power compared to what we previously did, which was to
re-check serial ports, PS/2, etc. every single loop in
the debugger, broken up only by "pause".
Change-Id: Ie421adae5c25ad6ae0c266d1d28c2ea7b81ae465
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9603
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
* If the CPUID bit is present, don't bother checking the models.
(This will happen on hypervisors.)
* Set the CPUID bit if we determine it's present.
* Only do this on CPU 0.
This massively cuts down on lock contention in Add(), since insertions
only acquire a write-lock in the case where a generation rolls over,
same as Lookup() does.
"git status" in buildtools, cold disk cache in a 4-core VM, seems about
the same, maybe slightly slower (~0.5s seemed typical, out of 20-21s),
while with a hot disk cache it's much faster: ~9.8s -> ~2.4s. Compile
performance seemed about the same.
Change-Id: Ia73f35fbbad3b3ac9ed783ea38cb8e2cb9818b5b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9580
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
The app_server will just ignore the request anyway in that case,
so we can save a round-trip.
This genericizes the change to BColumnListView done in
07f87734c5 (which will this be reverted.)
It seems to happen occasionally outside that context (I added logging
and saw it triggered dozens or more times in some applications.)
Using the new rw_lock, plus a spinlock for unused blocks.
This massively reduces lock contention on "git status". With
a cold disk cache (just after reboot) in a 4-core VM, "git status"
in the buildtools directory goes from ~33.4s down to ~20.1s, and with
a hot disk cache, from ~13.4s -> ~9.1s. Total time spent waiting on
the main lock goes from ~9-10 minutes down to ~5 in the cold case,
and in the hot case, down to < 1 second (instead there's ~2min
of wait time on the entry cache lock.)
It is probably worth noting that the unused spinlock is critical
to this working out. Without it, we still hit the fast path
hundreds of thousands of times in "git status", but the unlock-relock
happens often enough that it makes performance worse: I saw times of
40-50 seconds instead of 30 with that setup.
Change-Id: Ica8223ab6f1aacf65aa9b7408d980bb85c758ab9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9531
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Axel Dörfler <[email protected]>
They were originally out-of-line back when they used "khash",
but now that they use BOpenHashTable, there's no reason to
not inline them for efficiency.
Change-Id: I7279d3615ce85aee503e0ed60e8ca4c7ea6fcea4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9529
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This method is used in close_fd_index(), the normal path for close()
operations to go through. So, if a close() had been called on a
disconnected FD, before this commit we would just leak it.
This change means that close_fd() and put_fd() are called on
disconnected FDs being close()d. That's the same set of operations
that deleting an I/O context does, though, so this should
hopefully not cause any problems.
If we change our current directory, it will be retained as a reference
down inside the VFS, preventing filesystems from being unmounted,
among other things.
Fixes#19684.
Augustin Cavalier