Previously reads and writes to /dev/zero, /dev/full, /dev/null and
/dev/random were limited to 4096 bytes.
This removes that restriction so that users can enjoy more zero bytes
in their buffers.
Previously we'd just dump those packets into the network adapter's
send queue and hope for the best. Instead we should wait until the peer
has sent TCP ACK packets.
Ideally this would parse the TCP window size option from the SYN or
SYN|ACK packet, but for now we just assume the window size is 64 kB.
Previously we'd allocate buffers when sending packets. This patch
avoids these allocations by using the NetworkAdapter's packet queue.
At the same time this also avoids copying partially constructed
packets in order to prepend Ethernet and/or IPv4 headers. It also
properly truncates UDP and raw IP packets.
Previously TCPSocket::send_tcp_packet() would try to send TCP packets
which matched whatever size the userspace program specified. We'd try to
break those packets up into smaller fragments, however a much better
approach is to limit TCP packets to the maximum segment size and
avoid fragmentation altogether.
Since `s_mm_lock` is a RecursiveSpinlock, if a kernel thread gets
preempted while accidentally hold the lock during switch_context,
another thread running on the same processor could end up manipulating
the state of the memory manager even though they should not be able to.
It will just bump the recursion count and keep going.
This appears to be the root cause of weird bugs like: #7359
Where page protection magically appears to be wrong during execution.
To avoid these cases lets guard this specific unfortunate case and make
sure it can never go unnoticed ever again.
The assert was Tom's idea to help debug this, so I am going to tag him
as co-author of this commit.
Co-Authored-By: Tom <tomut@yahoo.com>
The Alternate Screen Buffer is used by full-screen terminal applications
(like `vim` and `nano`). Its data is stored separately from the normal
buffer, therefore after applications using it exit, everything looks
like it was before, the bottom of their interfaces isn't visible. An
interesting feature is that it does not support scrollback, so it
consumes less memory by not having to allocate lines for history.
Because of the need to save and restore state between the switches, some
correctness issues relating to it were also fixed in this commit.
This commit introduces support for 3 new escape sequences:
1. Stop blinking cursor mode
2. `DECTCEM` mode (enable/disable cursor)
3. `DECSCUSR` (set cursor style)
`TerminalWidget` now supports the following cursor types: block,
underline and vertical bar. Each of these can blink or be steady.
`VirtualConsole` ignores these (just as we were doing before).
I introduced a regression in #7184 where `TTY` would report 1 byte read
in canonical mode even if we had no more characters left. This was
caused by counting the '\0' that denotes EOF into the number of
characters that were read.
The fix was simple: exclude the EOF character from the number of bytes.
This still wouldn't be correct by itself, as the EOF and EOL control
characters could change between when the data was written to the TTY and
when it is read. We fix this by signaling out-of-band whether something
is a special character. End-of-file markers have a value of zero and
have their special bits set. Any other bytes with a special flag are
treated as line endings. This is possible, as POSIX doesn't allow
special characters to be 0.
Fixes#7419
Previously the process' m_profiling flag was ignored for all event
types other than CPU samples.
The kfree tracing code relies on temporarily disabling tracing during
exec. This didn't work for per-process profiles and would instead
panic.
This updates the profiling code so that the m_profiling flag isn't
ignored.
There's no good reason to distinguish between network interfaces based
on their model. It's probably a good idea to try keep the names more
persistent so scripts written for a specific network interface will be
useable after hotplug event (or after rebooting with new hardware
setup).
This is by default left empty, so people won't run the kernel in a mode
which they didn't want to. The embedded string will override the
supplied commandline from the bootloader, which is good for debugging
sessions.
This change seemed important for me, because I debug the kernel on bare
metal with iPXE, and every change to the commandline meant that I needed
rewrite a new iPXE USB image with a modified iPXE script.
First scan PCI bus 0. Find any device on that bus, and if it's a
PCI-to-PCI bridge, recursively scan it too.
Then try to handle Multiple PCI host bridges on slot 0, device 0.
If we happen to miss some PCI buses because they are not reachable
through recursive PCI-to-PCI bridges scanning starting from bus 0, we
might find them in this scanning.
This reverts commit e95eb7a51d.
This is causing some sort of list corruption, as evident by #7313
I haven't been able to figure it out yet, so lets revert this change
until I can figure out what's going on.
When mmaping a Framebuffer from userspace, we need to check whether the
framebuffer device is actually enabled (e.g. graphical mode is being
used) or a textual VirtualConsole is active.
Considering the above state, we mmap the right VMObject to ensure we
don't have graphical artifacts if we change the resolution from
DisplaySettings, changed to textual mode and after the resolution change
was reverted, we will see the Desktop reappearing even though we are
still in textual mode.
If we tried to change the resolution before of this patch, we triggered
a kernel crash due to mmaping the framebuffer device again.
Therefore, on mmaping of the framebuffer device, we create an entire new
set of VMObjects and Regions for the new settings.
Then, when we change the resolution, the framebuffersconsole needs to be
updated with the new resolution and also to be refreshed with the new
settings. To ensure we handle both shrinking of the resolution and
growth of it, we only copy the right amount of available data from the
cells Region.
Instead of processing the input after receiving an IRQ, we shift the
responsibility to the io work queue to handle this for us, so if a page
fault occurs when trying to switch the VirtualConsole, the kernel can
handle that.
I introduced this bug in e95eb7a51, where it's possible that the
ProcessGroup is created, but we never add it to the list. Make sure we
check that we are in the list before removal. This only broke booting in
self-test mode oddly enough.
Reported-By: Andrew Kaster <andrewdkaster@gmail.com>
Avoid allocating while holding the g_process_groups_lock spinlock, it's
a pattern that has a negative effect on performance and scalability,
especially given that it is a global lock, reachable by all processes.
Currently in SMP mode we hard code support for up to only 8 processors.
There is no reason for this to be a dynamic allocation that needs to be
guarded by a spinlock. Instead use a Array<T* with inline storage of 8,
allowing each processor to initialize it self in place, avoiding all
the need for locks.
Spinlocks guard short regions, with hopefully no other locks being taken
in the process. Violating constraints usually had detrimental effects on
platform stability as well as performance and scalability. Allocating
memory takes it own locks, and can in some cases even allocate new
regions, and thus violates these tenants.
Move the AnonymousVMObject creation outside of the spinlock as
creation does not modify any shared state.
Hook the kernel page fault handler and capture page fault events when
the fault has a current thread attached in TLS. We capture the eip and
ebp so we can unwind the stack and locate which pieces of code are
generating the most page faults.
Co-authored-by: Gunnar Beutner <gbeutner@serenityos.org>
