If we're constructing a FlyString from a StringView, and we already
have a matching StringImpl in the table, use HashTable::find() to
locate the existing string without creating a temporary String.
On my machine, it only sets PRC and not PCC.
Confirmed to happen on:
- 8086:9ca2 (Intel Corporation Wildcat Point-LP SATA Controller
[AHCI Mode] (rev 03))
On my bare metal machine, enabling it as this point causes it to
instantly send an interrupt, and we're too early in the process
to be able to handle AHCI interrupts. The interrupts were being
enabled in the initialize function anyway.
Confirmed to happen on:
- 8086:9ca2 (Intel Corporation Wildcat Point-LP SATA Controller
[AHCI Mode] (rev 03))
- 8086:3b22 (Intel Corporation 5 Series/3400 Series Chipset
6 port SATA AHCI Controller (rev 06))
Occasionally we'll see messages in the serial console like:
handle_tcp: unexpected flags in FinWait1 state
In these cases it would be nice to know what flags we are receiving that
we aren't expecting.
The following KUBSAN crash on startup was reported on discord:
```
UHCI: Started
KUBSAN: reference binding to null pointer of type struct UHCIController
KUBSAN: at ../../Kernel/Devices/USB/UHCIController.cpp, line 67
```
After inspecting the code, it became clear that there's a window of time
where the kernel task which monitors the UHCI port can startup and start
executing before the UHCIController constructor completes. This leaves
the singleton pointing to nullptr, thus in the duration of this race
window the "UHCI port proc" thread will go an and de-reference the null
pointer when trying to read for status changes on the UHCI root ports.
Reported-by: @stelar7
Reported-by: @bcoles
Fixes: #6154
AnonymousVMObject::create_with_physical_page(s) can't be NonnullRefPtr
as it allocates internally. Fixing the API then surfaced an issue in
ScatterGatherList, where the code was attempting to create an
AnonymousVMObject in the constructor which will not be observable
during OOM.
Fix all of these issues and start propagating errors at the callers
of the AnonymousVMObject and ScatterGatherList APis.
This change looks more involved than it actually is. This simply
reshuffles the previous Process constructor and splits out the
parts which can fail (resource allocation) into separate methods
which can be called from a factory method. The factory is then
used everywhere instead of the constructor.
This code was unlocking the lock directly, but the Locker is still
attached, causing the lock to be unlocked an extra time, hence
corrupting the internal lock state.
This is extra confusing though, as complete_current_request() runs
without a lock which also looks like a bug. But that's a task for
another day.
The separate backtrace that the PANIC emits isn't useful and just adds
more data to visually filter from the output when debugging an issue.
Instead of calling PANIC, just emit the message with dbgln() and
manually halt the system.
If we are attempting to emit debugging information about an unhandleable
page fault, don't crash trying to kill threads or dump processes if the
current_thread isn't set in TLS. Attempt to keep proceeding in order to
dump as much useful information as possible.
Related: #6948
As of ~April 2021 the Meta/build-image-grub.sh script no longer works
for me (on Fedora 34) and fails with the following error:
/usr/sbin/grub2-install: warning: ../grub-core/partmap/msdos.c:403:
your core.img is unusually large. It won't fit in the embedding
area.
/usr/sbin/grub2-install: warning: Embedding is not possible. GRUB
can only be installed in this setup by using blocklists. However,
blocklists are UNRELIABLE and their use is discouraged..
/usr/sbin/grub2-install: error: will not proceed with blocklists.
Changing the size of the boot partition from 32 kiB to 1 MiB (2048
sectors) fixes the issue. This is also described in the following Ubuntu
grub2 bug (as well as 40 duplicates!) from 2012, which suggests the same
fix: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1059827
The Arch Linux wiki also uses 1 MiB in their BIOS/MBR examples for
parted: https://wiki.archlinux.org/title/Parted
I'm not sure why this suddenly stopped working, however I was able to
boot with an image created with this change applied.
For whatever reason, symbolication was doing an O(n) walk of all the
symbols, despite having sorted them beforehand.
Changing this to a binary_search() makes symbolication noticeably
faster and improves Profiler startup time.
We were using ELF::Image::section(0) to indicate the "undefined"
section, when what we really wanted was just Optional<Section>.
So let's use Optional instead. :^)
By using fstatat during file system analyzation instead of lstat, we
reduce the amount of work the kernel has to do for each stat call.
During profiling it came up that the kernel was spending a lot of time
resolving paths. Because each call to stat passed an absolute path the
kernel had to do the same work over and over again.
When using relative paths the kernel only has to resolve the relative
part as it can reuse the already resolved path of the base directory.
The function fstatat can do the same thing as the stat and lstat
functions. However, it can be passed the file descriptor of a directory
which will be used when as the starting point for relative paths. This
is contrary to stat and lstat which use the current working directory as
the starting for relative paths.
It's technically not specified by POSIX, but it appears most Unix-like
systems worth mentioning put those definitions there. Also, it's more
logical since the dev_t type is defined there.
Instead of parsing untrusted and potentially malicious image files in
the ImageViewer GUI process, take advantage of the ImageDecoder service
that we already have on the system to sandbox the decode.
This prevents bugs in our image decoding libraries from being used as
an exploitation vector when viewing files in ImageViewer.
Previously you could pass anything (e.g a text file) to ImageDecoder and
it would "succeed" in decoding it and give you back a 0-frame result.
Let's consider that state a failure instead.
Single-process Browser forces a connection to these services early on,
to avoid having to unveil their paths. I'm suspicious of the benefits
of this (and the comment about it wasn't even accurate) but let's keep
it for now.
In multi-process mode, there's no need to do this, and in fact it was
causing us to spawn two extra totally unused processes.
Previously we didn't retransmit lost TCP packets which would cause
connections to hang if packets were lost. Also we now time out
TCP connections after a number of retransmission attempts.
This wakes up NetworkTask every 500 milliseconds so that it can send
pending delayed TCP ACKs and isn't forced to send all of them early
when it goes to sleep like it did before.
