When copying an area with vm_copy_area only the new protection would be
applied and any possibly existing page protections on the source area
were ignored.
For areas with stricter area protection than page protection, this lead
to faults when accessing the copy. In the opposite case it lead to too
relaxed protection. The currently only user of vm_copy_area is
fork_team which goes through all areas of the parent and copies them to
the new team. Hence page protections were ignored on all forked teams.
Remove the protection argument and instead always carry over the source
area protection and duplicate the page protections when present.
Also make sure to take the page protections into account for deciding
whether or not the copy is writable and therefore needs to have copy on
write semantics.
Change-Id: I52f295f2aaa66e31b4900b754343b3be9a19ba30
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3166
Reviewed-by: waddlesplash <[email protected]>
This enables generation of exceptions that are due to uncorrected
hardware errors. The exception handlers were already in place and will
now actually trigger kernel panics.
Note that this is the simplest form of MCE "handling" and does not add
anything of the broader machine check architecture (MCA) that also allow
reporting of corrected errors. As MCEs are generally hard to decode due
to their hardware specifity, this merely makes such problems more
obvious.
Might help to discern hardware issues in cases that would otherwise just
triple fault and cause a reboot.
Change-Id: I9e3a2640458f7c562066478d0ca90e3a46c3a325
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3155
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Axel Dörfler <[email protected]>
Without it, the device can't operate at all. Whether or not this is
enabled already is firmware dependent. It was off under QEMU when used
with "-soundhw ac97" and this makes the driver work there.
Fixes#10551 where the syslog shows that this can also happen on real
hardware that is otherwise fully configured.
Reserved areas don't have the name field initialized, so explicitly
print "reserved" instead.
Change-Id: I26bcfcb8facb8b5df11a58074506e96a41943e31
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2847
Reviewed-by: waddlesplash <[email protected]>
This makes the output of the aspace KDL command more useful as it shows
reserved and free ranges in addition to areas.
Change-Id: Id6353820b7c040fce6bfc3297c1b34adb1c9bb99
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2846
Reviewed-by: waddlesplash <[email protected]>
It allows an application to signal that it no longer needs the data in
the given address range and the underlying pages can be discarded and
reused elsewhere. This is finer grained than working with full areas
or mappings at a time and enables unmapping sections of partially used
mappings without giving up its address space.
Compared with punching holes into a mapping by "mapping over" with
PROT_NONE and MAP_NORESERVE, this has the obvious advantage of not
producing a lot of unused extra areas and saves the corresponding
resources. It is also a lot "lighter" of an operation than cutting
existing areas.
This introduces madvise() alongside the existing posix_madvise() to
allow for OS specific extensions. The constants for both functions are
aliased, the POSIX_MADV_* being a subset of the MADV_* ones without the
non-POSIX extensions. Internally posix_madvise() simply calls madvise().
MADV_FREE is commonly supported in other OSes with various subtle
semantic differences as to when pages are actually freed/cleared and how
or whether the pages are counted against the memory use of a process.
In the variant implemented here, pages are always immediately discarded
and memory counting is not altered. This behaviour should be considered
an implementation detail and may be altered later. The actual unmap and
discard could for example be delayed until pages are needed elsewhere to
reduce overhead in case of repeated discarding and remapping.
Note that MADV_FREE doesn't really align with the rest of the madvise()
API as it works like a command (i.e. discard these pages) and does not
add an attribute to the pages in the given range (i.e. mark these pages
for quick access from now on). As such, an MADV_FREE does not need to be
undone by setting a different advice later on, unlike how the other
flags work. This discrepancy may be the reason why it is not part of
POSIX.
Change-Id: Icc093379125a43e465dc4409d8f5ae0f64e107e0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2844
Reviewed-by: waddlesplash <[email protected]>
Pages in the given range are unmapped and freed without getting written
back anywhere. It can be used whenever a caller does not care about the
data in the given range anymore and wants to reduce page pressure.
Change-Id: I8bcce68fab278efef710d3714677e1d463504a56
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2843
Reviewed-by: waddlesplash <[email protected]>
The label to be truncated was copied into a fixed width buffer without
taking the null byte into account which would make
BFont::GetTruncatedStrings() read out of bounds when the name got long
enough. The output strings were also not allocated with the required
extra space for the ellipsis which would possibly have caused the
output to overflow.
Since the goal is to truncate a single string, remove the entire
temporary extra allocations and simplify to use BFont::TruncateString()
directly, which avoids both problems by being BString based.
Change-Id: Ib57430faf6f706c705497191000ee9686441857e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3116
Reviewed-by: waddlesplash <[email protected]>
The name retrieved from GetName() on BTextEncoding is owned by that
instance which goes out of scope when identify_text() returns. A const
char pointer to it can therefore not be used as an output variable. Use
a BString instead which ensures an appropriate reference is acquired.
Change-Id: Ib87fc9879d29e927bb41d1a9165ca7599b74a3bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3115
Reviewed-by: waddlesplash <[email protected]>
The panic is continuable, but moving on with the free will overrun the
array and corrupt memory.
Change-Id: I9a5849a40158042150a25740ca57d711aee872bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3114
Reviewed-by: waddlesplash <[email protected]>
If the vector is assigned to a CPU it means that the assignment
structure is still referenced from the CPU side and must not be reset.
This can happen when an interrupt vector is freed that still has a
handler installed, i.e. when the order of removing the handler and
freeing the vector is reversed.
Change-Id: Ib2dc5fa8f95a28b36e8f150dc8f16236ca4b2275
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3113
Reviewed-by: waddlesplash <[email protected]>
The old buffer info was not initialized so would possibly contain bogus
initial content.
Since the introduction of the TimeComputer, the old buffer info was not
used to update the timesource data and the only remaining use was for
keeping track of the previous cycle number.
Replace the old buffer info by just the old cycle number and initialize
that.
Change-Id: I8be5a17f086a9f81f9b8fd0629e10460518f3d8c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3111
Reviewed-by: waddlesplash <[email protected]>
Two indices into the fEntries ring buffer are used in TimeComputer,
fLastEntry which points to the most recent sample and fFirstEntry which
points to the oldest one. The drift calculation then uses the oldest
values pointed at by fFirstEntry to produce smoother values.
Both indices are initialized to 0, then fLastEntry is incremented prior
to writing the first sample, resulting in the first sample to be written
to fEntries[1]. When drift is calculated on subsequent samples, they
were using the uninitialized data from fEntries[0] due to fFirstEntry
still pointing there, until enough samples had been added for
fFirstEntry to be moved forward. The resulting incorrect drift values
would depend on the entry content and ratio between real and performance
time and generally end up being much too small.
The drift values are published on the time source and used to correct
the conversion between performance and real time in
BTimeSource::RealTimeFor(). Given the incorrectly small drift values,
this conversion produced real time values far in the future, causing
increased delays in processes that wait for such computed real times.
One likely victim was the startup of the AudioMixer, as it generally
starts soon after the driver and its MultiAudioNode. If it started right
in the time window where the drift was broken, it would end up delaying
its initial buffer processing by a factor generally depending on the
difference between real and performance time start points, so usually
the difference of the start of the boot process to the start of the
audio driver.
The symptom was then noticable by initial silence after boot, as the
mixer was not producing any buffers until the wrongly calculated real
time had been reached. After that, lots of queued up events were
processed at once, resulting in a CPU spike and glitchy audio for a
couple of seconds after which audio finally normalized. As the problem
was in the MultiAudioNode all mutli audio drivers were affected, HDA
being the most prominent.
As the erroneous delay depended on the initial entry content and the
boot time, it was highly variable. Whether or not the mixer was affected
at all also depended on it starting reasonably early after the driver,
which made the symptom of the bug appear and disappear depending on
slight timing changes, making unrelated code changes look like they were
affecting the bug.
The fFirstEntry index is now updated to fLastEntry after the initial
entry is added, so that the drift calculation always uses valid data.
Fixes#16222, may also affect #15472 and possibly other "no audio"
tickets in case they are really "delayed" audio tickets.
Change-Id: I61f4a67e8b8bf14d2f311cb41b24a1c385aebc19
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3092
Reviewed-by: waddlesplash <[email protected]>
This ensures that the allocated physical memory uses 32 bit addresses.
Also avoid writing to the 64 bit address registers when the controller
is not 64 bit.
Change-Id: I58008d68bcd9579903534f824db2660f73e39160
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3065
Reviewed-by: waddlesplash <[email protected]>
The spec says that changing the DMA memory addresses of a stream should
really only be done after a reset and before the first run. Stopping the
stream is not enough, as the controller is allowed to cache the
addresses even when the stream is paused.
Note that this is applied to both, the initial configuration of buffers
and to the case of dynamically changing stream parameters. In the initial
case this should always be a no-op as the controller was previously
globally reset.
In the dynamic reconfiguration case this fixes random memory corruption
due to the controller still accessing and modifying physical memory that
is released by the driver. With some controllers, such corruption was
easily triggered by changing the input and output sampling rates for the
HDA device in the media preferences.
The return value of the reset call is intentionally not checked to allow
for it to partially or fully fail. At least for HDA under QEMU, the
stream reset fails to start, while the initial stream stop still works
and prevents the memory corruption.
Change-Id: I7c6e6547ee08889a2990de26d5eed5e73b2ca13c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3063
Reviewed-by: waddlesplash <[email protected]>
Don't unconditionally enable PCI interrupt generation as this only
applies when MSIs are not in use. Delay the evaluation and setting of
the interrupt disable bit until after it is clear whether or not MSIs
are to be used.
Initially force interrupt generation off as early as possible. Depending
on the initial state of the controller, some spurious interrupts might
come up and we really don't want them to occur before everything is set
up in the right way.
Change-Id: Ifb12f5eef1cbf8ecfa3f352564139125d8ad2169
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3062
Reviewed-by: waddlesplash <[email protected]>
This is already properly done in uninit_driver.
Putting the module in device instead of driver uninit meant that on a
device reopen the gPCIx86Module would always be gone and therefore MSIs
could not be used anymore even if they previously were.
Change-Id: Ib3bddefbe6bcb02fa1c97f3c843cecaf31c80e3e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3061
Reviewed-by: waddlesplash <[email protected]>
Just disabling it will leak the vector reservation and makes it
impossible to configure an MSI on the device again.
Also removes the check for the gPCIx86Module as having an MSI configured
really implies its presence.
Change-Id: I9f0e3e63c988af515d23ad93d86918cde9add97a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3060
Reviewed-by: waddlesplash <[email protected]>
In the start case this adds debug output in case a start fails.
For stops this makes sure the stream DMA engine has actually stopped
operating, which is a precondition for some other operations.
Change-Id: I0e2731513febd0e0cd4e1f0ef89cf3d7312a47e1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3058
Reviewed-by: waddlesplash <[email protected]>
It is a recurring pattern to set some bits, then wait for them to be
read as set or the reverse. For resets this is done once in both
directions, so factoring this out removes quite a bit of similar code.
No functional change intended.
Change-Id: I2ae4b6cce490c33e1a027328f01fbffea67c5180
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3057
Reviewed-by: waddlesplash <[email protected]>
Factor out the conversion to BAR index and hand the pci_info to both
memory and IO port allocation functions. Then apply the same checks
in the IO port case as are done for memory.
This aligns with what is done on FreeBSD.
Change-Id: Ib4bd28fd861959a467ba676de22efb1f97e5a27c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3025
Reviewed-by: waddlesplash <[email protected]>
Fix address type mask to use the right bits via PCI_address_type. The
previous 0xc value applies to the upper of the two address type and
the prefetchable bit instead of the two adddress type bits. This would
cause prefetchable 64 bit BARs to be misidentified as not being 64 bit.
Remove address masking as this is already done on the field in pci_info.
Use uint64 instead of phys_addr_t explicitly as on pure 32 bit platforms
this would otherwise result in a shift greater than type size.
Note that the sizes should theoretically be adjusted as well, but in all
of these cases a size needing the upper 32 bits doesn't make much sense.
Change-Id: Idd0d6e9a6cc18656b43cafcac720b132fc1f2ad3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3024
Reviewed-by: waddlesplash <[email protected]>
Make mandatory argument of _GetRomBarInfo a reference too and use NULL
instead of 0 for pointer argument default value.
Some line length cleanup.
Change-Id: I1bdb59eeae4496b75fd4a1b8c5b305283da266f9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3023
Reviewed-by: waddlesplash <[email protected]>
This moves the entire 64 bit handling into _GetBarInfo() and applies it
to the PCI address and size too. Previously only the RAM address was
handled for the 64 bit case.
Also fixes the 64 bit check to be done after the type determination.
Previously it would theoretically be possible for an IO BAR with the
lowest address bit set for that type (bit 3) to be mistaken to be 64 bit
and then skipping/mishandling the next BAR. Due to alignment this would
have needed to be a 4 byte IO BAR though.
This also corrects the limit for 64 bit BARs of type 1 devices. As there
are only two slots, only slot 0 can be 64 bit.
Also removes a copy&paste error that would lead to the high address of
64 bit BARs of type 1 devices to get taken from the h0 instead of h1
struct, corrupting its value.
Make the mandatory arguments to _GetBarInfo() references to make the
distinction more obvious and replace 0 with NULL in the default values.
Change-Id: Iae59f2875c93f15411a4d9791e71e69ba7a42287
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3022
Reviewed-by: waddlesplash <[email protected]>
Previously system_info->free_swap_pages was using swap_available_pages
which has reservations removed. Tools like ActivityMonitor would
therefore show mere reservations as swap use which is misleading at
best.
Switch to use the sum of the free slots of all swap files instead.
This doesn't add overhead as the swap file list was already locked and
traversed for max_swap_pages before (via swap_total_swap_pages()).
Fixes#16248.
Change-Id: I3ebf223ec108bf342d4f32d68405170e72528899
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2917
Reviewed-by: Axel Dörfler <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
This allows dumping the allocation stack traces in the more powerful
allocations command with the optional "trace" argument. The stack trace
could previously only be dumped manually by inspecting individual
guarded heap pages.
The team is locked for the allocation of the user thread. When the
thread limit is reached, the user thread is removed again by
team_free_user_thread which internally locks the team, resulting in a
double lock. Unlock the teamLocker before calling team_free_user_thread.
Amazingly noone seems to ever have hit the thread limit, even though it
is currently at an arbitrarily low 4096.
The rename of the system_info members was missed in
d02aaee17e (part of the scheduler branch
merge of hrev46690). The unguarded object_cache was introduced even
earlier as part of hrev43133.
The BStackOrHeapArray was allocated with one byte less than user_strlcpy
would write to, corrupting random heap memory. The error was introduced
as part of hrev53864.
Fixes#16175.
Change-Id: I80e1a1bb104183545fbd2a2702cdf3dec089908d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2860
Reviewed-by: waddlesplash <[email protected]>
The possible insertion range for B_*_ANY_ADDRESS always encompasses the
entire address space. Even though the initial starting point is now
looked up using a binary search tree, actually finding a free spot was
then still done using a linear search from there.
Store a simple insertion hint, the address directly following the
previous insertion of the same type, and use that as the next starting
point. In the common case this reduces the needed iterations to zero or
near zero.
No hint is used for B_*_BASE_ADDRESS specs as it is assumed that the
given base address already serves as such a hint.
Fixes the area creation performance part of #15995.
Change-Id: Ia8ce76eadc341b71de4cf8c34744c2459473bd06
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2842
Reviewed-by: waddlesplash <[email protected]>
It iterates over all areas intersecting a given address range and
removes the need for manually skipping uninteresting initial areas. It
uses VMAddressSpace::FindClosestArea() to efficiently find the starting
area.
This speeds up the two iterations in unmap_address_range and one in
wait_if_address_range_is_wired and resolves a TODO in the latter hinting
at such a solution.
Change-Id: Iba1d39942db4e4b27e17706be194496f9d4279ed
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2841
Reviewed-by: waddlesplash <[email protected]>
This introduces VMAddressSpace::FindClosestArea() that can be used to
find the closest area to a given address in either direction. This is
now trivial and efficient since both kernel and user address spaces use
a binary search tree.
Using FindClosestArea() getting multiple area infos is sped up
dramatically as it removes the need for a linear search from the first
area to the one given in the cookie on each successive invocation.
Change-Id: I227da87d915f6f3d3ef88bfeb6be5d4c97c3baaa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2840
Reviewed-by: waddlesplash <[email protected]>
This is analogous to the AVLTree used for kernel address ranges in
VMKernelAddressSpace. It does not use an additional DoublyLinkedList
however.
Using a binary tree speeds up many operations that previously had to
iterate the area list linearly to find normal and reserved areas,
insertion start points, etc. It especially benefits LookupArea which is
called for every page fault and from area_for() when randomly accessing
different areas as that would make the previously used area hint (i.e.
a one level lookup cache) ineffective.
The overhead of the tree versus the doubly linked list for iteration,
insertion and removal is reasonably small and pales in comparison to
what the linear searches previously took up.
Fixes the lookup performance in #15995.
Change-Id: I48319fe6a2e4327826e90ebca7246c7c419b5218
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2839
Reviewed-by: waddlesplash <[email protected]>
They return the left and right most nodes of the entire tree, i.e.
starting from the root node.
Change-Id: I651a9db6d12308aef4c2ed71484958428e58c9bc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2838
Reviewed-by: waddlesplash <[email protected]>
It combines the intersection check and setting address, size and offset
so that they fall within the area.
Change-Id: Iffd3feca75d4e6389d23b9d70294253b4c3d1f4c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2837
Reviewed-by: waddlesplash <[email protected]>
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 <[email protected]>
This allows switching from another recursive_lock, mutex or read-locked
rw_lock analogous to the switching possibilities already in mutex.
With this, recursive_locks can be used in more complex situations where
previously only mutexes would work.
Also add debugger command to dump a recursive_lock.
Change-Id: Ibeeae1b42c543d925dec61a3b257e1f3df7f8934
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2834
Reviewed-by: waddlesplash <[email protected]>
The memory map may be unordered and include overlapping ranges. To make
sure that nothing gets included as usable that should actually be
excluded, first scan for all usable ranges and add them, then remove
anything unusable from these ranges again.
To calculate the amount of unusable memory, count the total after the
first pass and then subtract the total after the second. This way, only
unusable ranges that actually overlap physical memory (and therefore
reduce the amount of usable memory) get excluded.
Note that the explicit ignore of the ACPI reclaim memory is subsumed by
the above. We still don't want to add this region to the usable memory
map, as that would allow the kernel to allocate pages into that region,
possibly corrupting ACPI tables before they were used. We also don't
want to add it as an allocated range, as it is not guaranteed that ACPI
is done with the tables before the unused bootloader ranges are freed in
the kernel.
Also add the missing unusable memory amount from ignoring the first MiB
of memory in the EFI loader.
May fix#16056 although it is not certain that graphics memory ranges
are actually included in the memory map.
Change-Id: Ie7991d2c4dcd988edac2995b3a7efc509fa0f4a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2814
Reviewed-by: waddlesplash <[email protected]>
This reverts hrev54120 and instead adds the commonly supported
MAP_NORESERVE flag to request overcommit.
Using PROT_NONE for overcommit is problematic as the protection of
individual pages can still be changed via mprotect to make them
accessible, but that won't change the commitment. An application
using such a pattern may then unexpectedly run into out of memory
conditions on random writes into the address space.
With MAP_NORESERVE the overcommit can explicitly be requested by
applications that want to reserve address space without producing
memory pressure.
Change-Id: Id213d2245c5e23103e8e0857f7902e0cd8a2c65d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2611
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
The use of individual _SwapBlockGetAddress() and _SwapBlockFree() calls
would lock and unlock the swap hash for each page.
Using _FreeSwapPageRange() also allows to skip entire blocks when they
are not present or get empty early.
Change-Id: Ia76735e514cf8967d282e099cf5409fe1b104297
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2590
Reviewed-by: waddlesplash <[email protected]>
Rename MovePageRange to Adopt and group it with Resize/Rebase as it
covers the third, middle cut case.
Implement VMAnonymousCache::Adopt() to actually adopt swap pages. This
has to recreate swap blocks instead of taking them over from the source
cache as the cut offset or base offset between the caches may not be
swap block aligned. This means that adoption may fail due to memory
shortage in allocating the swap blocks.
For the middle cut case it is therefore now possible to have the adopt
fail in which case the previous cache restore logic is applied. Since
the readoption of the pages from the second cache can fail for the same
reason, there is a slight chance that we can't restore and lose pages.
For now, just panic in such a case and add a TODO to free memory and
retry.
Change-Id: I9a661f00c8f03bbbea2fe6dee90371c68d7951e6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2588
Reviewed-by: waddlesplash <[email protected]>
Otherwise pages from it would later be tried to be written back with
nowhere to go in case of temporary caches.
Change-Id: I81e7335408c419a9b2c7bbb31290d551f5508d56
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2586
Reviewed-by: waddlesplash <[email protected]>
When only some initial slots of a block were filled, the block would
become unused early and get freed. The iteration for the remaining slots
would then operate on the stale swapBlock as the pointer was not reset.
As we already know that the remaining slots can't be in use, directly
skip to the next swap block to avoid needless hash lookups.
Change-Id: Ib25377beb092aaf3533de1786b5f4c1099464599
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2584
Reviewed-by: waddlesplash <[email protected]>
The pageIndex is incremented on loop, so rounding up to the next swap
block would skip the first entry of the next block which would leak its
swap slot.
Change-Id: Ief3d29e711d323756034ea5ba6e300c489198aff
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2583
Reviewed-by: waddlesplash <[email protected]>
Except for the offsets the code was identical. Also simplify the
conditions with early returns.
Change-Id: Ia7c44578ab06e571f6bf992db6c6d3493fd93230
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2582
Reviewed-by: waddlesplash <[email protected]>
When bounce buffers were changed from fixed to dynamic in hrev27185, the
early unlock in case of physical vectors was not removed. This would
lead to an unprotected fBounceBuffers list and the possibility for
multiple operations to share the same bounce buffer vecs, leading to
disk corruption. This would not happen when used purely under the
IOScheduler as all translations are done from a single thread there.
With the nvme_disk driver that runs requests in parallel, this was
however easy to trigger.
Change-Id: I46bd55cd5d86174523d3f745b6c8800dae02babc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2524
Reviewed-by: waddlesplash <[email protected]>
The context buffer needs to be freed manually. This was already done
correctly in the destructor, but was missing from the error case.
This lead to a leak of at least 32K for the initial allocation or
potentially a lot more, depending on how much avformat_open_input
extended it for probing.
Change-Id: Ib4c751c7de9430926ae82b397803ac93ecfffe5d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2038
Reviewed-by: Stephan Aßmus <[email protected]>
Previously the CCB would never complete when a timeout occured, leading
to all further IO stopping.
Abort the request by setting the CCB status to aborted and handing the
CCB back to the SCSI layer. That one will then handle the error (and
possibly retrying). This is similar to how such errors are handled in
AHCI and the ATA stack.
Since it is now possible that we receive a completion interrupt for an
already aborted request, we need to keep track of what request the
interrupts belong to and only notify when the current one completes. As
there currently can't be multiple requests in flight, a simple counter
is used.
Change-Id: Ib80e146605efd2f81123803f424cc7f66f52a6c8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1815
Reviewed-by: waddlesplash <[email protected]>
It previously returned the cookie directly, which made it impossible
to distinguish between a NULL cookie and the function not having
anything to dequeue. This lead to some code setting a cookie that was
not actually used.
Return the dequeue status as a boolean and provide the cookie with an
optionally handed in pointer instead and adjust all users.
Change-Id: Iaac1726ac4bc7ae42bb96b8f0915852b6def5822
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1814
Reviewed-by: Jérôme Duval <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
As soon as the lock is released, fCCB may change due to a new Start().
With the current use of the request class this could not happen, so
this is purely theoretical.
Change-Id: I6caee7f904f1864621aeef088e2bd611eb3b0a1f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1813
Reviewed-by: Adrien Destugues <[email protected]>
The value is never actually checked. The use of a condition variable
makes it redundant since it will already either have a waiting entry,
or not.
Change-Id: Iafaecb7f9e56a2cf8932e05b82aad2b350fbce1f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1812
Reviewed-by: Jérôme Duval <[email protected]>
It has lower overhead and allows to name the areas so that they are
labeled as heap areas.
Note that we can still use munmap for releasing. It has the nicer
interface of using the base address and length which we already know
instead of needing the area id that would have to be queried with an
additional syscall.
Change-Id: I338c4043ecc2947b82b8fe9fd69a99ce3fa23138
When CopyEngine::_CopyFolder() would recursively call itself, the
fCurrentTargetFolder would be set to the entry name of that directory.
When this returned, this was never reset to the parent directory name
and would eventually use a freed string when the BEntry was reused
for the next entry.
The constructor calls for GlobalDescriptorTable and
InterruptDescriptorTable were run on each CPU, each time clearing out
any changes already done on other CPUs.
For the IDT this didn't matter as the result would always be the same.
In case of the GDT the result would surprisingly be mostly hidden. The
used GDT entries are for the double fault stacks (which is rarely hit),
the user TLS (which will only be used in compat mode) and the TSS which
is immediately cached in the task register.
The clearing of the GDT allowed for a tiny window of time between
setting up the entry for the TSS and it actually being loaded (and
cached) in the task register. When this happened, the load of the TR
caused a not present fault, which at this point leads to a tripple
fault and reset due to no fault handlers being installed yet.
Fixes#14659.
Change-Id: I6e5c00d412ab17c3ef05740ba71228e6ca266c1e
Reviewed-on: https://review.haiku-os.org/810
Reviewed-by: Jérôme Duval <[email protected]>
This was apparently copied from GlobalDescriptorTable::SetTSS() which
needs two table entries and therefore checks for index + 1. For the
SetUserTLS case this isn't needed and would cause aborts when reaching
the maximum CPU count (64 currently).
Change-Id: I27bd777fedadbd3740ac8c791199ec9300b06327
Reviewed-on: https://review.haiku-os.org/809
Reviewed-by: waddlesplash <[email protected]>
The normal locking uses spinlocks that require getting at the current
CPU, which in turn needs a current thread set. This has not been set up
at this point and would simply cause tripple faults.
Use manual locking using atomic ops instead.
Change-Id: Ica894389330ef481eec84b667234139746ac4a46
Reviewed-on: https://review.haiku-os.org/808
Reviewed-by: waddlesplash <[email protected]>
Many of the consumers fill in data into preallocated arrays. Some of
them already ignored values past the array size manually, some didn't.
Add a maxChar argument and set it from the incoming array sizes for
the various consumer cases.
Variable length arrays on the stack are always risky when the length
is indeterminate as they can easily overflow the stack. Replace their
use by BStackOrHeapArray, fixes#6354.
Also replace most other dynamic allocations by BStackOrHeapArray as
it is more convenient and may avoid unnecessary dynamic allocations.
Add allocation checks and early returns to all places while at it.
There was no synchronization of the check of the done flag and the
waiting thread suspending to wait for it. It was therefore possible that
the new team both set the flag and triggered the wakeup of the waiting
thread in that time window, causing it to miss both the set flag and the
thread resumption.
Use a condition variable instead.
Fixes#13081.
Change-Id: I93c45db8dd773fe42b45c4b67153bcd39e200d3b
Reviewed-on: https://review.haiku-os.org/803
Reviewed-by: waddlesplash <[email protected]>
This allows heap implementations to initialize and clean up any thread
specific structures. The current default hoard heap does not use these.
Note that the thread exit hook will not be called for the main thread as
the heap may be needed during process termination (__cxa_finalize for
example).
Change-Id: I703fbd34dec0d9029d619a2125c5b19d8c1933aa
Reviewed-on: https://review.haiku-os.org/799
Reviewed-by: waddlesplash <[email protected]>
The buffers were allocated with B_ANY_KERNEL_ADDRESS and the buffer plus
header block would produce uneven sizes. This lead to some buffers
crossing page boundaries. The call to get_memory_map() is only supplied
with a single entry, which in such a situation may not be enough if the
physical pages are not contiguous. Due to missing result checks this was
not noticed.
Use B_ANY_KERNEL_BLOCK_ADDRESS and align the size of the total buffer
to avoid such page boundary crossing.
Fixes randomly truncated frames in the receive path.
Previously the frame length was set to the allocation size of the buffer
itself, which is constant. Use the length returned on dequeing instead,
which tells how much of the buffer was actually filled.
Fixes overly long frames that lead to various problems along the receive
path.
The size was in fact the count of physical entries that were used. That
number must necessarily be the same as the number given when adding to
the queue, so that number isn't really interesting. Consequently none
of the users of that API made use of it.
Return the used length instead, which is the way virtio signals how much
valid data resides in the dequeued buffer. This is for example important
to know the frame length of incoming packets in virtio_net.
We reuse the incoming request buffer to send our reply. We did however
not trim that buffer to the length we actually filled out, allowing
any extraneous incoming data to remain in that buffer and be sent back.
The action vm_page_fault takes should depend on whether the iframe to be
handled is a user iframe or not. The check for the user flag in the
error code does however only check if the fault happend in user or
kernel space. Use IFRAME_IS_USER() instead which checks the privilege
level of the iframe. Under 32 bit x86 this also handles vm86
compatibility mode properly.
This is the same logic as used on FreeBSD (TRAPF_USERMODE).
Fixes#13930.
Change-Id: I9c348b6ab4c60daaaaa2c0fe33bcc3336aa29f7b
Reviewed-on: https://review.haiku-os.org/560
Reviewed-by: Axel Dörfler <[email protected]>
Since wait_for_objects can wait on sems, threads and ports in addition
to FDs, limiting to RLIMIT_NOFILES as in the select/poll case does not
work. Since space is allocated for the wait objects in kernel memory,
limiting their number to a valid range is still desireable.
The limit is now placed at the sum of max sem, thread and port count
plus RLIMIT_NOFILES.
This also fixes a signed vs. unsigned comparison warning in
check_max_fds introduced in hrev51866.
It was limited to a uint32 and could for example be overflown by the
slab MemoryManager that uses size_t on a 64 bit system.
This aligns the signature with create_area() that already uses size_t
for the size argument.
Note that the function is currently private, so the impact should be
limited.
The scheduler uses the load tracking logic to compute the load of
threads to be enqueued into the run queue. The time delta between the
last enqueue and the next enqueue may grow very large for threads
that mostly wait on conditions. In such cases the int "n" period count
variable would become too small and wrap around, leading to an
assertion failure.
For this to happen, the thread in question would have to have slept for
at least ~25 days and then wake up. Threads often affected would be ones
waiting for some other process to end, for example shell threads waiting
for a long running process to exit.
Fixes#13558.
Michael Lotz