mirror of
https://github.com/RGBCube/serenity
synced 2025-07-25 03:17:35 +00:00
Kernel: Zero-fill faults should not temporarily enable interrupts
We were doing a temporary STI/CLI in MemoryManager::zero_page() to be able to acquire the VMObject's lock before zeroing out a page. This logic was inherited from the inode fault handler, where we need to enable interrupts anyway, since we might need to interact with the underlying storage device. Zero-fill faults don't actually need to lock the VMObject, since they are already guaranteed exclusivity by interrupts being disabled when entering the fault handler. This is different from inode faults, where a second thread can often get an inode fault for the same exact page in the same VMObject before the first fault handler has received a response from the disk. This is why the lock exists in the first place, to prevent this race. This fixes an intermittent crash in sys$execve() that was made much more visible after I made userspace stacks lazily allocated.
This commit is contained in:
parent
b880f1928a
commit
b0321bf290
1 changed files with 4 additions and 3 deletions
|
@ -293,9 +293,10 @@ bool MemoryManager::zero_page(Region& region, unsigned page_index_in_region)
|
|||
ASSERT_INTERRUPTS_DISABLED();
|
||||
auto& vmo = region.vmobject();
|
||||
auto& vmo_page = vmo.physical_pages()[region.first_page_index() + page_index_in_region];
|
||||
sti();
|
||||
LOCKER(vmo.m_paging_lock);
|
||||
cli();
|
||||
ASSERT(vmo.is_anonymous());
|
||||
|
||||
// NOTE: We don't need to acquire the VMObject's lock.
|
||||
// This function is already exclusive due to interrupts being blocked.
|
||||
|
||||
if (!vmo_page.is_null()) {
|
||||
#ifdef PAGE_FAULT_DEBUG
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue