Until now, our kernel has reimplemented a number of AK classes to
provide automatic internal locking:
- RefPtr
- NonnullRefPtr
- WeakPtr
- Weakable
This patch renames the Kernel classes so that they can coexist with
the original AK classes:
- RefPtr => LockRefPtr
- NonnullRefPtr => NonnullLockRefPtr
- WeakPtr => LockWeakPtr
- Weakable => LockWeakable
The goal here is to eventually get rid of the Lock* classes in favor of
using external locking.
Instead of having two separate implementations of AK::RefCounted, one
for userspace and one for kernelspace, there is now RefCounted and
AtomicRefCounted.
After commit 91a03bc6ae we no longer try
to discover files for exec-ing by simply trying to exec on them, but we
check for the files existence by using `Core::file::exists()` first.
Contrary to the old solution, this now requires the `rpath` pledge, so
pledge it to keep `strace` from crashing when using non-absolute paths.
All users which relied on the default constructor use a None lock rank
for now. This will make it easier to in the future remove LockRank and
actually annotate the ranks by searching for None.
Unlike Clang, GCC does not support 8-byte atomics on i686 with the
-mno-80387 flag set, so until that is fixed, implement a minimal set of
atomics that are currently required.
Signal dispatch is already protected by the global scheduler lock, but
in some cases we also took Thread::m_lock for some reason. This led to
a number of different deadlocks that started showing up with 4+ CPU's
attached to the system.
As a first step towards solving this, simply don't take the thread lock
and let the scheduler lock cover it.
Eventually, we should work in the other direction and break the
scheduler lock into much finer-grained locks, but let's get out of the
deadlock swamp first.
This is not necessary, and is a leftover from before Thread started
using the ListedRefCounted pattern to be safely removed from lists on
the last call to unref().
As soon as we've saved CR2 (the faulting address), we can re-enable
interrupt processing. This should make the kernel more responsive under
heavy fault loads.
This fixes an issue where a sharing process would map the "lazy
committed page" early and then get stuck with that page even after
it had been replaced in the VMObject by a page fault.
Regressed in 27c1135d30, which made it
happen every time with the backing bitmaps used for WebContent.
This mirrors the "open parent directory" action, but traverses the
breadcrumbbar segments from left-to-right instead. The name is a little
bit strange, and maybe we can come up with something better.
It does feel pretty nice to use though. :^)
Region::physical_page() now takes the VMObject lock while accessing the
physical pages array, and returns a RefPtr<PhysicalPage>. This ensures
that the array access is safe.
Region::physical_page_slot() now VERIFY()'s that the VMObject lock is
held by the caller. Since we're returning a reference to the physical
page slot in the VMObject's physical page array, this is the best we
can do here.
Note that SMP is still off by default, but this basically removes the
weird "SMP on but threads don't get scheduled" behavior we had by
default. If you pass "smp=on" to the kernel, you now get SMP. :^)
We really only need the VMObject lock when accessing the physical pages
array, so once we have a strong pointer to the physical page we want to
remap, we can give up the VMObject lock.
This fixes a deadlock I encountered while building DOOM on SMP.
When handling a page fault, we only need to remap the faulting region in
the current process. There's no need to traverse *all* regions that map
the same VMObject and remap them cross-process as well.
Those other regions will get remapped lazily by their own page fault
handlers eventually. Or maybe they won't and we avoided some work. :^)
- Instead of holding the VMObject lock across physical page allocation
and quick-map + copy, we now only hold it when updating the VMObject's
physical page slot.
Noticed that mouse-overing the ruler area in the TextEditor
does not change the cursor to the default cursor, instead, the
beam cursor is used, which does not look nice.
This PR extends the mousemove event and introduces a new
set_editing_cursor() function that takes care of setting the
cursor for the editor area.
Commit 75d1840cf detects if the initial path provided to the FileManager
contains a dotfile, and if so, forces the FileManager to show dotfiles.
However, it does this by activating the "Show Dotfiles" action. This has
the side effect of always setting and persisting the configuration,
overriding whatever the user's preference was.
Instead, only transiently update the view to show dotfiles if the path
contains a dotfile.
The order of PNG compression is raw pixel data -> filter -> compress.
For decompression, the order is reversed, so that means uncompress ->
unfilter -> raw pixel data. Previously, the PNG decoder was converting
to raw pixel data before unfiltering, which was a problem when using
indexed color palettes, since each pixel's palette index could change
during unfiltering (e.g. it was unfiltering after already choosing
the color from the palette index). This was leading to 'Palette index
out of range' errors on files that both:
- Had scanlines with some sort of filtering
- Didn't use the full range of possible palette indices for their bit
depth.
Also, because filtering now happens before converting to pixel data,
filtering acts on bytes instead of pixels, meaning that the
implementation of each filter type now maps much more directly to
the specification:
http://www.libpng.org/pub/png/spec/1.2/PNG-Filters.html
Make sure we reject the unveil attempt with EPERM if the veil was locked
by another thread while we were parsing argument (and not holding the
veil state spinlock.)
Thanks Brian for spotting this! :^)
Amendment to #14907.
To ensure that we stay on the same CPU that acquired the spinlock until
we're completely unlocked, we now leave the critical section *before*
re-enabling interrupts.
We want to grab g_scheduler_lock *before* Thread::m_block_lock.
This appears to have fixed a deadlock that I encountered while building
DOOM with make -j2.
Path resolution may do blocking I/O so we must not do it while holding
a spinlock. There are tons of problems like this throughout the kernel
and we need to find and fix all of them.
This fixes an issue where we could get preempted after acquiring the
current Processor pointer, but before calling methods on it.
I strongly suspect this was the cause of "Processor::current() == this"
assertion failures.
