Anhad Singh
a8699a7e72
This commit fixes the following panic when running nodejs:
```
KERNEL PANIC: panicked at src/context/memory.rs:267:18:
grant cannot magically disappear while we hold the lock!
FP ffff80002021f650: PC ffffffff8005e45b
FFFFFFFF8005E2E0+017B
kernel::panic::panic_handler_inner
FP ffff80002021f730: PC ffffffff80057559
FP ffff80002021f740: PC ffffffff8009a0ff
FP ffff80002021f770: PC ffffffff8009c214
FP ffff80002021f7d0: PC ffffffff80010997
FFFFFFFF8000FDD0+0BC7
kernel::context::memory::AddrSpaceWrapper::mprotect
FP ffff80002021fd40: PC ffffffff8008cb0b
FFFFFFFF8008CA40+00CB
kernel::syscall::process::mprotect
FP ffff80002021fd70: PC ffffffff8006ce6c
FFFFFFFF8006CBE0+028C
kernel::syscall::syscall
FP ffff80002021fe90: PC ffffffff8008d3cf
FFFFFFFF8008D320+00AF
__inner_syscall_instruction
FP ffff80002021ff50: PC ffffffff800830c3
FFFFFFFF80083080+0043
kernel::arch::x86_64::interrupt::syscall::syscall_instruction
00007ffffffffaf0: GUARD PAGE
CPU #1, CID 0xffffff7f8015b910
NAME: /usr/bin/node, DEBUG ID: 74
SYSCALL: mprotect(0x203C0000, 262144, Some(MapFlags(0x0)))
HALT
```
The grant did not magically disappear. When going through the
`grant_span_res` regions, the function adds (and removes) grants to the
`self.grants` tree. The insertion and deletion functions also merge
adjacent grants together when possible. This is an issue since we can no
longer use the keys we established before we started iterating. This
commit modifies the places where `remove` is used in this fashion to use
`remove_containing` instead. The `remove_containing` function will
remove the grant that *contains* the page.
Should it be done this way (requires unstable feature `btree_cursors`)?
Signed-off-by: Anhad Singh <andypython@protonmail.com>
Kernel
Redox OS Microkernel
Requirements
nasmneeds to be available on the PATH at build time.
Building The Documentation
Use this command:
cargo doc --open --target x86_64-unknown-none
Debugging
QEMU
Running QEMU with the -s flag will set up QEMU to listen on port 1234 for a GDB client to connect to it. To debug the redox kernel run.
make qemu gdb=yes
This will start a virtual machine with and listen on port 1234 for a GDB or LLDB client.
GDB
If you are going to use GDB, run these commands to load debug symbols and connect to your running kernel:
(gdb) symbol-file build/kernel.sym
(gdb) target remote localhost:1234
LLDB
If you are going to use LLDB, run these commands to start debugging:
(lldb) target create -s build/kernel.sym build/kernel
(lldb) gdb-remote localhost:1234
After connecting to your kernel you can set some interesting breakpoints and continue
the process. See your debuggers man page for more information on useful commands to run.
Notes
-
Always use
foo.get(n)instead offoo[n]and try to cover for the possibility ofOption::None. Doing the regular way may work fine for applications, but never in the kernel. No possible panics should ever exist in kernel space, because then the whole OS would just stop working. -
If you receive a kernel panic in QEMU, use
pkill qemu-systemto kill the frozen QEMU process.
How To Contribute
To learn how to contribute to this system component you need to read the following document:
Development
To learn how to do development with this system component inside the Redox build system you need to read the Build System and Coding and Building pages.
How To Build
To build this system component you need to download the Redox build system, you can learn how to do it on the Building Redox page.
This is necessary because they only work with cross-compilation to a Redox virtual machine, but you can do some testing from Linux.
Funding - Unix-style Signals and Process Management
This project is funded through NGI Zero Core, a fund established by NLnet with financial support from the European Commission's Next Generation Internet program. Learn more at the NLnet project page.
