From ba2f78e12b8939df18e966b502106928438566c2 Mon Sep 17 00:00:00 2001 From: vasilito Date: Fri, 10 Jul 2026 00:45:40 +0300 Subject: [PATCH] kernel: replace OOM panic with graceful log-and-continue Previously: PfError::Oom during page fault recovery caused the entire kernel to panic via todo!("oom"). This means a single OOM allocation in a user process would crash the whole OS. Now: OOM is logged as a warning, the faulting process receives SIGSEGV (same path as other non-fatal page faults), and the kernel continues. The process may be killed, but the system stays up. This is consistent with how Linux handles OOM during page fault handling: send SIGSEGV/SIGKILL, don't panic. --- src/memory/mod.rs | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/memory/mod.rs b/src/memory/mod.rs index ac4064cac5..4516247ad3 100644 --- a/src/memory/mod.rs +++ b/src/memory/mod.rs @@ -1027,7 +1027,13 @@ pub fn page_fault_handler( let mut token = unsafe { CleanLockToken::new() }; match context::memory::try_correcting_page_tables(faulting_page, mode, &mut token) { Ok(()) => return Ok(()), - Err(PfError::Oom) => todo!("oom"), + Err(PfError::Oom) => { + log::warn!("page fault recovery failed: out of memory at {:#x}", faulting_page.start_address().data()); + // OOM during page table correction is non-fatal: the process + // receives SIGSEGV but the kernel continues. The faulting + // allocation will be retried or the process killed by the OOM + // killer when it's implemented. + } Err(PfError::Segv | PfError::RecursionLimitExceeded | PfError::NonfatalInternalError) => (), } }