we check the OpRegion version and use the rvda pointer when available.
from 2.1 the pointer is relative.
Change-Id: I64d8aea65368aa3c5597f63a2b96b6a430e04315
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5109
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* solves #17659
* We assigned the volume label to the root, but not the boot
sector (partition boot sector, not MBR)
Change-Id: I9c53204c18709c2d225cc8ea338290aa89d42083
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5106
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Obtain the size of local package files.
Fixes #17445
Change-Id: Ica15d3f7c1e80bcf9b3b23d6af851cc33b5b6253
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5016
Reviewed-by: Andrew Lindesay <apl@lindesay.co.nz>
Yet another 16550 clone under a different name. Why does device-tree
have a "compatible" setting if everyone puts a different name for the
same thing?
Change-Id: Ia889a527a36739df747ba48d4606c09764703607
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5103
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
They were hardcoded to 2, which is not correct on all devices. As a
result, getting addresses and sizes on pure 32bit devices would fail.
Change-Id: Icf542c9e8d6b7136219014fe08dd601387de4762
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5102
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
If mprotect() is being run over an entire area, and the area does
not have per-page protections, then we can just invoke set_area_protection
instead of allocating a protections array.
This is a major efficiency increase, as every page fault would otherwise
have to use the protections array if it was allocated.
Testing with QtWebEngine shows this new path being hit relatively often
(multiple hundred times in loading a single webpage).
Change-Id: I60258d56f681060861602922f3fbdbce2fd380d6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5097
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* We should not assume all non-kernel areas have KERNEL_READ_AREA
permission, but follow the other permission flags directly.
This way the kernel will be blocked from accessing guard pages, too.
* Compute kernelProtection only once, and either return it directly
or return it OR'd with the user protections.
Change-Id: Id6daa1cd15eb3102e23f95c08672ad97344e0722
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5096
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>
It already checks for area->page_protections == NULL and returns
area->protection appropriately if so, we do not need to test specifically
for that here.
No functional change intended.
It's entirely possible that we have a user area with a page that
has protections of 0 (e.g. a guard page). In that case we should
print the standard read/write fault message instead of "kernel"
fault messages.
This should not be a major behavioral change, only the syslog
and tracing entries should be affected; such memory accesses
should be caught by the read/write permissions checks immediately
following.
It seems this is the type of the innermost source cache, not the
topmost cache (which well may be "RAM" if this is an anonymous cache
on top of a Vnode cache.)
Originally VMArea::cache_type was introduced 15 years ago
(commit 0c12332715, 2007)
merely to mirror the underlying cache's type. Somewhere along the way,
it acquired different values. As the VM has changed a lot since then,
perhaps its overall purpose should be re-evaluated?
Fixes #17556.
If these methods are called while the interface in question
is receiving data via a receive thread, we can hit a deadlock
where a receive thread is holding the receive lock and then
tries to call get_interface_address_for_link (due, e.g., to ipv4
checking is_local_link_address), which tries to acquire the interfaces
lock, while at the same time we are trying to acquire the receive lock
due to CreateDomainDatalinkIfNeeded invoking a module's datalink_init
which calls register_device_handler, so we deadlock. (Whew!)
As far as I can tell, we do not need to set Busy() here despite unlocking
the interfaces lock, as the Interface acquires its own lock in
CreateDomainDatalinkIfNeeded.
Observed in VMware when the DHCP client spins for a long time,
and the deadlock occurs upon opening Network preferences.
Instead add a second level to the loop and a small temporary array.
Makes the code slightly simpler (and safer, as there is no risk
of races now.)
Also add a missing "firstCPU +" in the current_frequency calculation.
It seems that has been broken since the frequency value was introduced...
In addition to being slightly more efficient, this also allows one
to see precisely how many vnodes are currently "alive" across all
mounts via the "slabs" KDL command.
Part of the point of published variables is to make them "shareable",
and not require external synchronization. Requiring the callers
to ensure unpublishing does not occur is thus unreasonable, as e.g.
a variable could be unpublished immediately after being notified.
That is the case for some usages of these variables in the FreeBSD
compatibility layer, which under heavy usage, can and did trigger
use-after-unpublishes and then KDLs, at least in local testing.
Instead, only unlock the hash after we have locked the variable.
This is already done in some other functions, so it's safe to do
it here, too. This way, the variable won't be unpublished
while Notify() is running.
This resolves a TODO, and allows B_KERNEL_RESOURCE_ADDRESS_SPACE
to be a bit more useful, as fragmentation will now turn in
to a low-resource notification.
We never included obprintf in the build, and the real obstack.h
exists in the "extensions" folder. Unfortunately, it seems the
BeOS R5 libroot had an obstack.h in the public POSIX headers
directory and exported the functions, so we cannot remove it
completely just yet.
Pascal Abresch
Augustin Cavalier