Branding fix across all 3 architectures to match the active Red Bear
identity. Previously the kernel fork's start messages still claimed
'Redox OS starting' on aarch64, riscv64, and x86_shared, while the
canary/debug patches added later correctly used the new branding.
This commit completes the user-facing branding pass: after this, every
Red Bear OS boot logs 'RedBear OS starting...' instead of 'Redox OS
starting...'.
Patches applied:
- kernel/P2-redbear-os-branding: 2 of 3 architecture files automatically
patched via patch(1) fuzz=5
- kernel/src/arch/x86_shared/start.rs: 1 hunk applied via fuzz=2; the
remaining 'Redox OS starting' literal updated via direct edit since
patch context for that line was already canary-disturbed
dup_into previously returned EEXIST when the target fd slot was already
occupied, causing procmgr panics during bootstrap. The fix matches dup2
behavior: close the target fd first, then insert the new one.
Also removes diagnostic crate::info! logging added during root cause
investigation of the FD table desync between userspace FILETABLE and
kernel posix_fdtbl.
Per local/docs/PATCH-PRESERVATION-AUDIT-2026-07-12.md the kernel
fork was carrying only 21 of 45 patches in local/patches/kernel/.
The other 24 patches' content was silently missing from the fork
working tree, even though their .patch files were preserved.
This commit re-applies 7 patches that genuinely still apply
cleanly. The other 17 patches in the orphan list had hunks that
were already partially present in the fork (conservative audit
flagged them as orphan but the changes were material and only
partially diverged) or no longer apply (file was restructured
upstream). After this commit, the kernel fork reflects the
intended Red Bear work for:
- P1-memory-map-overflow: stack-guard on startup memory map
- P3-eventfd-kernel: scheme support for eventfd fd-table ops
- P5-context-mod-sched: context-switch optimization (mod.rs)
- P8-msi-foundation: MSI/MSI-X driver foundation (src/arch/x86_shared/device/msi.rs)
- P8-msi: device-level MSI plumbing (vector.rs)
- P9-proc-lock-ordering: scheme/proc lock ordering fix
- redox: Makefile patch
Untracked files msi.rs and vector.rs created by patch application.
mtn/ tree and proc.rs.orig cleaned up (leftovers from absolute-path
patch context lines).
The RB fork's KernelScheme trait has an extra 'arg: u64' parameter in
kfdwrite (not in upstream). Also RB's FileDescriptor has a 'cloexec' field.
Both are now handled correctly.
This merge uses -X ours to preserve ALL upstream functions while keeping
all RB-specific features (cpuinfo, iostat, msr, facs, fadt, s3_resume,
+rb0.3.1 version). The kfdwrite function that was lost during a bad
merge (7aa2a165) has been surgically restored from upstream/master.
Missing upstream functions still pending restoration:
- bulk_insert_files, resize in context.rs
- insert_hole, remove_hole, resize_hole in memory.rs
- eq, hash, get_event_stat, read_with_timeout in event.rs
- kcall in debug.rs
- __syscall_instruction_end in syscall.rs
The AddrSpaceSwitchReadGuard was acquired in select_next_context() and stored
in percpu.new_addrsp_guard, but NEVER consumed/released. This held a read lock
on the address space forever, causing usermode_bootstrap's acquire_write() to
deadlock — the bootstrap process could never start.
The guard is redundant: CONTEXT_SWITCH_LOCK + context write guards in
SwitchResultInner already protect the address space during the switch.
Matching upstream commit ca67b1da which has no AddrSpaceSwitchReadGuard.
AddrSpace handles from dup(b'empty') and dup(b'exclusive') use the write
syscall for mmap commands, not seekable I/O. The kwriteoff handler returns
the mapped address (not bytes written), which sys_write would incorrectly
add to the file offset when POSITIONED is set. This corrupted the offset,
causing the next write to fail with EINVAL (offset_word skip exhausted
the buffer). Only mmap-min-addr needs POSITIONED for actual read/write.
The previous default only accepted u64::MAX as 'stream write' offset, but
sys_write/sys_read pass offset=0 for non-positioned I/O. This caused
ESPIPE on all writes to non-positioned FDs (Debug/stdout). Now both
u64::MAX and 0 are accepted as 'no offset' for the default implementation.
Schemes that override kwriteoff (AddrSpace) still handle offset=0 correctly.
The default kreadoff/kwriteoff implementations in scheme/mod.rs require
offset=u64::MAX for stream (non-positioned) I/O. Passing offset=0 causes
ESPIPE (Illegal seek), which breaks ALL writes to non-positioned FDs
including Debug/stdout. This was the root cause of the procmgr child
appearing to 'panic' — its log output silently failed with ESPIPE.
The addr_space_lock.mmap() result must be used or explicitly ignored.
Use let _ = ... to discard it — if mmap fails here, the process
crash will be more informative than a Result warning.
- syscall/futex.rs: scope the context write guard so futexes.swap_remove
can borrow mutably after the guard drops
- syscall/process.rs: add missing 'shared' arg to Grant::zeroed
The bump allocator previously had no way to track which frames are
free for reuse. Add a FreeNode struct that records (next, count,
phys) for freed regions, enabling frame recycling after initial
identity-mapping setup is complete.
The .map_err().?() pattern doesn't work in a function returning (),
because ? requires the enclosing function to return Result. Replace
with plain .expect() (these are bootstrap initialization failures —
if mmap fails here, the kernel cannot continue).
The initial bootstrap init (started directly by the kernel via
usermode_bootstrap) had RSP = 0 from InterruptStack::init(), which
does NOT set RSP. This caused any push/call in the binary to fault
on address 0.
The Rust panic handler caught the resulting page fault and generated
ud2 — visible as 'Invalid opcode fault' at a low RIP before main()
ever runs. This was the root cause of the init crash.
Fix:
- Map 8 pages (32 KiB) of user stack just above the initfs image
- Set RSP to the top of the stack
- Add debug log showing the mapped region
The stack is intentionally small (32 KiB) — enough for Rust _start
to run but small enough to detect stack overflow immediately. Once
init calls fexec_impl to spawn the real init, the real init gets its
own full 8 MB stack via the redox-rt exec path.
- rmm/src/arch/emulate.rs: replace unimplemented!() with actual TLB
invalidation (remove the address from the map). Without this the
emulate arch silently fails to invalidate TLB entries during
context switches, which can cause stale mappings.
- src/syscall/futex.rs: remove completed TODO marker for FUTEX_REQUEUE
(work done in a prior commit).
The sys_mkns and sys_setns functions added in 48fc2f1c reference
UserSliceRo and FileHandle but the imports were not updated, causing
the build to fail with 'cannot find type' errors. This commit adds
the missing imports.
Adds proper kernel-level namespace syscall handling:
- SYS_MKNS: dups the current namespace fd with the caller-supplied
buffer (NsDup::ForkNs + scheme names). The dup is handled by the
bootstrap's userspace namespace manager (initnsmgr) which creates
the new namespace and returns the fd.
- SYS_SETNS: switches the calling context's ns_fd to the given fd.
This makes the new namespace the default for all subsequent scheme
lookups by this context.
- Context gains an ns_fd: Option<usize> field, initialized to None,
meaning "use the global namespace" (default).
- Both syscalls are wired into the dispatch table in syscall/mod.rs.
Per local/docs/LOCAL-FORK-SUPREMACY-POLICY.md: the kernel fork must
be complete. Previously SYS_SETNS was undefined and SYS_MKNS returned
ENOSYS; init's setrens() panicked on bare metal.
sys_read and sys_write passed u64::MAX as the offset for non-positioned
file descriptors. Many scheme handlers (AddrSpace, proc:Start, etc.)
check offset != 0 or offset % word_size != 0, causing EINVAL when
receiving u64::MAX. Passing 0 instead fixes all non-positioned read/write
operations across all scheme handlers uniformly.
This replaces the per-handler u64::MAX workarounds with a root-cause fix.
sys_write passes u64::MAX as offset for non-positioned file descriptors.
ContextHandle::Start used an inline 'offset != 0' check which rejected
u64::MAX, causing EINVAL when bootstrap called start_fd.write(&[0]) during
fork_inner(). Replaced with require_zero_offset() which accepts both 0 and
u64::MAX (fixed in the previous commit for the same class of bug).
sys_write passes u64::MAX as the offset sentinel for non-positioned file
descriptors. The proc scheme's require_zero_offset rejected this value,
causing bootstrap's tcb_activate to crash with EINVAL when writing
EnvRegisters (fsbase) back to the regs/env handle.
This was the root cause of the 'Invalid opcode fault' during bootstrap
(PID 0) that prevented redbear-mini from reaching a login prompt.
vasilito
R Aadarsh