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).
Instead of using a simple switch to determine if preemption is enabled
(`is_preemptable: bool`), a counter is used instead. This handles the
case where a function holding a `PreemptGuard` calls another function
that creates a new `PreemptGuard`.
Signed-off-by: Anhad Singh <andypython@protonmail.com>
The global allocator panics when out of memory rather than returning an
errors. In addition there are plenty of other places where we don't
handle allocation failure anyway. At some point in the future we should
systematically handle out of memory conditions, but until then let's not
pretend we do and get rid of the usage of the unstable allocator_api
feature that is unlikely to get stabilized any time soon.
vasilito
Akshit Gaur